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ABSTRACT 


A student team at the Naval Postgraduate School studied the need for, and 
development of, a system that effectively and economically deters piracy in an area of 
interest. The system’s proposed area of operation is the Gulf of Aden, but the system 
may be deployed to any operational theater where piracy threatens maritime commerce. 
Piracy and hijacking of ships off the Somali Coast have grown tenfold since 2006. In 
response to this growing problem, the U.S. Navy, along its with allies, formed Combined 
Task Force 151 (CTF-151) to protect approximately 33,000 merchant vessels transiting 
through this area daily. CTF-151 patrols the Internationally Recommended Transit 
Corridor (IRTC) in the Gulf of Aden and because of this, Somali pirates have begun to 
migrate away from the IRTC and CTF-151 patrols. For this reason, the team studied the 
use of UAV technology that allowed for broader area of piracy surveillance and 
detection. The system that was conceived and analyzed was the Oceanic Armed 
Reconnaissance System (OARS). The OARS Basic alternative, when analyzed against 
CTF-151, was found to be the most cost effective system. This OARS Basic system is 
comprised of a Littoral Combat Ship (LCS) as a host vessel, ScanEagle UAVs, an SH-60 
Helicopter, and Zodiac Rigid Hulled Inflatable Boats (RHIB). 
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EXECUTIVE SUMMARY 


Piracy and hijacking of ships off the Somali Coast has increased drastically over 
the last five years. In an attempt to counter these pirate acts and provide friendly cargo 
vessels with safe passage through the Gulf of Aden, the U.S. Navy, along with its allies, 
formed Combined Task Force 151 (CTF-151). This task force provides safe passage for 
cargo vessels by patrolling a narrow strip of the Gulf of Aden, called the Internationally 
Recommended Transit Corridor (IRTC). CTF-151’s presence along the IRTC has driven 
pirates further away into other areas of the Gulf of Aden and the Indian Ocean. 

As Systems Engineering students studying at the Naval Postgraduate School, this 
problem was brought to our attention and became the focal point of our research. The 
need for an anti-piracy system with a larger area of coverage became evident. From this 
need, our team decided to investigate the use of Unmanned Aerial Vehicle (UAV) 
technology to aid in covering a larger area of ocean. The system that was conceived and 
analyzed was called the Oceanic Armed Reconnaissance System (OARS). 

At the end of our research and analysis, the system that was found to be the most 
cost effective in regards to piracy detection and deterrence was the “OARS Basic” 
alternative. The subsystem components that comprise OARS Basic are a Littoral Combat 
Ship (LCS), ScanEagle UAVs, an SH-60 Helicopter, and Zodiac Rigid Hulled Inflatable 
Boats (RHIB). Performance of six of these OARS Basic systems were compared against 
the current CTF-151 ships. 

Our research team began our work by first outlining the scope of the problem and 
by researching current technology. After outlining the scope of the problem and 
conducting a technology feasibility analysis, our team then developed a concept of 
operations (CONOPs) for two different OARS variations, OARS Basic and OARS 
Augmented. These concepts included the use of an array of existing UAV technology, 
which would be integrated into a host vessel platform. Besides being used for 
surveillance and reconnaissance, the UAVs will also collect live-video of pirate activity, 
which will provide stronger evidence in court for convicting pirates of crimes. 
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The goal of the host vessel was to provide surveillance and interdiction of pirate 
activity, which could be supplemented with pursuit and interdiction craft, such as RHIBs 
and helicopters. The OARS Augmented alternative included everything from the Basic 
OARS alternative, but also utilized a long range airship or Broad Area Maritime 
Surveillance (BAMS) UAV to increase detection and surveillance potential. The 
feasibility of these systems was supplemented by information from subject matter experts 
and stakeholders. 

The team conducted a House of Quality (HOQ) analysis to quantify which design 
characteristics were most critical to the stakeholders. The team determined that Detect 
and Track were the most valuable design characteristic, as indicated from the associated 
weighted metrics. To gauge the effectiveness of these design characteristics during 
OARS system modeling and design, twelve Key Performance Parameters (KPPs) were 
selected from a pre-determined list of Measures of Performance (MOPs). Some of these 
KPPs included percent of pirate detection, coverage area, intercept time, and number of 
engagements. These twelve KPPs became the test metrics for system comparison during 
the modeling and simulation phase. 

After the functional and physical architectures had been derived, the team 
generated seven alternatives for physical OARS systems. These seven alternatives were 
comprised of different combinations of OARS subsystems. Each alternative outlined 
specific guns, missiles, communication systems, radars, sensor equipment, vessels, 
helicopters, and UAVs, all of which are currently mature systems. In an effort to 
facilitate rapid deployment and reduced cost, only existing warfare systems with high 
technology readiness level (TRL) were considered as subsystem variants. The critical 
variants considered in this process were the host vessel, helicopter, pursuit vessel, and 
UAV. 

The emergent preferred alternative, which we deemed as “OARS Basic,” 
incorporated the use of an LCS host vessel, a SH-60 helicopter, Zodiac RHIBs as pursuit 
vessels, and ScanEagle UAVs. The team also indicated a second alternative, referred to 
as “Augmented OARS,” which incorporated a BAMS UAV for additional aerial 
surveillance. 
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Using these two identified alternatives, OARS Basic and Augmented OARS, the 
team built models of each and simulated their operations using the Naval Simulation 
System (NSS) software. Each scenario contained the same environmental modeling 
parameters, which consisted of: 355 transiting cargo vessels, 100 pirate motherships, and 
200 pirate skiffs. The model environments spanned 390,000 square miles of ocean in the 
Gulf of Aden and simulated anti-piracy operations during a 30 day period. During data 
analysis, the team focused on particular NSS data measurements which were relevant to 
original stakeholder MOEs. OARS Basic proved to be slightly more capable of 
neutralizing and deterring pirate motherships, while also detecting 35% more pirates than 
CTF-151. This is attributed to the fact that OARS Basic had four times more airborne 
UAYs than CTF-151 and suggests that simply the presence of UAVs deters pirate 
activity. 

During the last week of modeling and simulation runs, the OARS team’s 
modeling and simulation databases were inadvertently erased. This resulted in the loss of 
all software models and prohibited the OARS team from extracting the modeling results 
of the OARS Augmented alternative. For this reason, CTF-151 was only compared 
against the OARS Basic alternative. 

The cost analysis showed that OARS Basic has a Life Cycle Cost (LCC) of 
$15.5B, which is 12% cheaper than CTF-151’s LCC of $17.5B. Using these LCCs and 
the effectiveness results from the modeling and simulation analysis, the OARS team 
recommends the OARS Basic alternative to be utilized in future anti-piracy missions. 
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I. INTRODUCTION 


A. OBJECTIVE 

The objective of this project was to develop a system that effectively and 
economically deters piracy in an area of interest. The system’s current area of operation 
is the Gulf of Aden, but the system may be deployed to any operational theater where 
piracy threatens maritime commerce. 

B. BACKGROUND 

Piracy has re-emerged as a problem to the international maritime community. 
Piracy is a worldwide concern for all vessels traveling the open seas. Piracy is defined as 
consisting of: 

“ ...any of several acts, including any illegal act of violence or detention, 
or any act of depredation, committed for private ends by the crew or the 
passengers of a private ship and directed against another ship, aircraft, 
persons, or property onboard another ship on the high seas; or against a 
ship, persons or property in a place outside the jurisdiction of any state ” 
(Maritime Security: Actions Needed to Assess and Update Plan..., GAO 
2011 ). 

Although piracy could happen anywhere across the global seas, piracy near the shores of 
Somalia, including the Gulf of Aden, Southern Somalia Basin, and Western Indian 
Ocean, has grown in staggering proportion over the last five years. Table 1 illustrates the 
growing numbers of Somalia based pirate attacks over the last 5 years (United States 
General Accountability Office (GAO), "Maritime Security: Updating U.S. Counterpiracy 
Action Plan... 2011). In 2006, Somali Piracy accounted for only 9% of the global piracy 
attempts. Today, Somali Piracy accounts for over 60% of the worldwide total pirate 
attempts (International Maritime Bureau, 2011). 

Modern day pirates are usually armed with very intimidating weaponry, including 

long knives, AK-47 assault rifles, and Rocket Propelled Grenades (RPGs). Somali pirates 

are not centrally controlled, but have a common mission. That mission is to hijack high 

value ships, hold the crew members hostage, and extort millions of dollars in ransom 

money. Hundreds of attacks are recorded each year. Pirates have captured dozens of 
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ships, held thousands of hostages, and have cost the maritime community severely in 
losses and spent revenue (IMB Piracy Report 2010-2011). 

Pirates utilize motherships and smaller skiffs to commit piracy acts. The 
motherships can be any large vessel, including fishing vessels, yachts, or large industrial 
vessels that have recently been hijacked. When a target vessel is spotted, the pirates 
launch the smaller skiffs and proceed to board and hijack the vessel. Pirate skiffs usually 
carry between four and eight passengers, can have twin out-board engines, contain large 
quantities of fuel, and often contain ladders and grappling hooks for boarding. 
Depending on the victim vessel, pirates can board and take over a vessel in less than 20 
minutes (GAO, “Maritime Security: Updating U.S. Counterpiracy Action Plan, 2011). 

1. Current Anti-Piracy Solutions 

The Combined Task Force 151 (CTF-151) is currently deployed within the Gulf 
of Aden to combat piracy. CTF-151 is a multinational task force that was established in 
2009 to conduct counter-piracy operations. In the Gulf of Aden, CTF-151 patrols the 
Internationally Recommended Transit Corridor (IRTC). The IRTC is a narrow passage 
way through the Gulf of Aden that was created after piracy escalated in the area 
(Combined Maritime Forces 2011). The IRTC allows CTF-151 to concentrate its patrols 
and has helped to deter some piracy in the Gulf of Aden, but unfortunately, piracy still 
remains a threat to everyone who transits near the Horn of Africa. CTF-151 patrols the 
IRTC and even escorts merchant vessels from time to time. However, most of CTF- 
151 ’s anti-piracy operations are initiated by distress calls from merchant vessels that are 
already being attacked by pirates. 

2. Current Limitations to Combating Somali Piracy 

What makes Somali Piracy difficult to counter is the pirates’ lack of definitive 
characteristics that separate them from the fishermen and civilians. The fact is that most 
Somali pirates are ex-fishermen and operate on fishing vessels. The Horn of Africa, 
especially within the Gulf of Aden, is a very popular fishing area to the natives. This 
means that there are a multitude of innocent fishing vessels in the area, which makes it 
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very difficult for anyone to identify pirates before they actually commit a crime 
(Christensen 2009). 

Another downside to effectively combating piracy is the maritime legal 
restrictions placed upon naval forces when facing pirates. 

“A state of war does not exist therefore the law of armed conflict does not 
apply - pirates cannot be targeted as if they were combatants. Force can 
only be used against pirates in either self-defense / defense of others or to 
stop the vessel in order to board it - its use must be avoided as far as 
possible and, where unavoidable, must not go beyond what is reasonable 
and necessary in the circumstances ’’ (Christensen 2009). 

This makes it difficult to stop piracy in its tracks. Even when a distress call is 
received and the pirates are intercepted by CTF-151, it is hard to collect incriminating 
evidence against the pirates to convict them of any crimes. This is due to the fact that 
pirates will often throw their paraphernalia (weapons, ladders, ammunition, etc.) 
overboard if they spot CTF-151 naval vessels. 


3. UAV Technology in the Deterrence of Piracy 

In order to combat these deficiencies, the OARS Capstone team pursued the use 
of UAV technology in anti-piracy operations. The use of UAV technology in anti-piracy 
operations will allow for: 

• A broader area of surveillance coverage. This allows the OARS system to 
be easily transferable to other pirate-infested waters, and ultimately, 
anywhere in the world where piracy is an issue. 

• A better source of video-footage and imagery of pirate vessels. These 
images and video surveillance can be used as incriminating evidence 
against the pirates to ensure that when caught, they will serve jail time for 
their intentions and not just be “caught and released,” as is the current 
norm. Even though it is often difficult to determine whether or not a 
vessel is a pirate vessel, there are some tell-tale signs that the UAVs can 
search for that can aid in determining suspicious vessels. These are: long 
ladders, large quantities of fuel drums, guns and ammunition crates, and 
large quantities of men (upwards of 8 to 10 men in a single small skiff). 

• An ever-present “eye in the sky” mentality that will keep the pirates 
always looking over their shoulder. The fact that the pirates know that 
they could be under surveillance at any given time by UAVs will make 
them less willing to commit acts of piracy. 
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C. SCOPE AND ASSUMPTIONS 

1. Scope 

Pirates use a flexible mode of operation and operate in an area that spans 
hundreds of square miles. They can lay dormant in an area for weeks or attack almost 
daily against any ship within their range. 

Due to its large concentration of ship traffic and its proximity to the Somali coast 
line, the Gulf of Aden has been the main focus of Somali piracy attempts. Table 1 shows 
the number of piracy attempts that are attributed to Somali Pirates. 


Table 1. Locations of All Attempted and Actual Somalia Piracy Acts from 
2006 to 2011 (From IMB Piracy Report, 2010-2011). 


Locations 

2006 

2007 

2008 

2009 

2010 

2011 (Jan- 
June, 

6 months) 

Somalia 

10 

31 

19 

80 

139 

125 

Gulf of Aden 

10 

13 

92 

117 

53 

20 

Red Sea 




15 

25 

18 

REST OF Arabian Sea 

2 

4 


1 

2 


WORLD Indian Ocean 




1 



Oman 


3 


4 










Yearly Totals of SOMALIAN PIRATE 
Attacks/Attempts 

22 

51 

111 

218 

219 

163 

Yearly Totals of WORLDWIDE 
Attacks/Attempts 

239 

263 

293 

410 

445 

266 

Percentage of SOMALIAN PIRATE 
Attacks vs. the WORLD WIDETotals 

9% 

19% 

38% 

53% 

49% 

61% 


Due to the fact that the Gulf of Aden is a natural chokepoint and that over 33,000 
ships transit its waters every year, the OARS team focused on prevention of piracy within 
the Gulf of Aden (GAO, "Maritime Security: Updating U.S. Counterpiracy Action Plan, 
2011 ). 
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2. Assumptions 

To meet such a challenge, the OARS team developed the following list of initial 
system needs and assumptions: 

The OARS system should: 

• Focus on the Gulf of Aden similar to CTF-151. 

• Adhere to the Navy’s Seapower-21 concept and its net-centric maritime 
domain awareness doctrine. 

• Be deployable by 2020 and capable of defending all shipping from piracy, 
within the current 1.1 million square mile operational area of CTF-151. 

• Be capable of neutralizing pirates and then arresting, detaining & 
maintaining evidence for continued prosecution. 

• Be developed jointly with international interests. 

• Be supportable by current DoD logistics systems. 

• Have increased use of ship borne UAV platforms (Off the shelf UAVs, 
where any modifications would be limited). 

• Utilize non lethal UAV deterrence (Where pirates will get the message but 
not be killed). 

• Comply with International Law. 

• Developed as cost effectively as possible. 

D. SYSTEMS ENGINEERING METHODOLOGY AND APPROACH 

The OARS system engineering process consisted of Mission Conceptualization, 
Concept of Operations, Requirements Analysis, System Development, System Analysis, 
System Verification, System Integration, and Recommendations. 

The OARS team utilized the systems engineering “Vee” diagram as a guideline 
for creating a tailored system engineering process. The classic “Vee” was then adapted 
to fit our unique anti-piracy mission, to meet the need for early mission development, to 
be consistent with our capstone schedule, and to meet the goals and focus of our 
Modeling and Simulation effort. Figure 1 illustrates the OARS systems engineering 
process (Buede 2009, Ch. 1). 
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The schedule of our capstone project consisted of three academic quarters of 
work, with a main reporting milestone at the end of each quarter (each quarter consisted 
of approximately three months). These milestones were the In Progress Review (IPR) 
#1, IPR #2, and the Final Brief. Both of the IPRs were presentations where our team 
briefed our current progress, findings, and path forward, to our project advisors, 
stakeholders, classmates, and other NPS faculty. The Final Brief was a presentation that 
summarized all of our work, conclusions, and recommendations. Due to the fact that our 
work was divided by three distinct milestones, we divided our systems engineering 
approach into three distinct sections, as shown in Figure 1. 

The three different color shades display the specific areas of work that were to be 
completed or in-process by each milestone IPR. The green arrows show the feed forward 
requirements of the process. The blue arrows show the feedback loops in the system as 
the system was developed, requirements were found, and the team’s knowledge of the 
subject area grew. The black diamonds displayed are the major milestone reviews that 
were completed at each stage of the system development. The elements of the system 
design were reiterated in place, to transform the piracy threat from a nebulous series of 
issues to a definable, model-able, and scalable solution (Maier and Rechtin 2009, Ch. 1). 

1. Mission Conceptualization 

The Mission Conceptualization block contained the effort to define the 
operational requirements for the system and to validate the feasibility of those 
requirements. The block consisted of the mission development, operational 
requirements, and feasibility analysis. The mission development was the team’s initial 
work and starting point for a concept to meet the piracy threat. This was done to identify 
and mitigate possible team biases for the deployment of the system. Such biases included 
an overdependence on airship technologies, and a preference for the Broad Area 
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Maritime Surveillance (BAMS) Unmanned Aerial Support (UAS) system. The 
operational requirements listed the possible environments and situations the system 
would be expected to encounter, such as the Gulf of Aden environment. The Feasibility 
Analysis set the limits of the system to coincide with the timeframe, cost, and technology 
maturity of the possible system solution. Although this step did not finalize a list of 
requirements, it set the framework for the requirements analysis, and the development of 
the Concept of Operation (CONOPS) for the OARS system. 

2. Concept of Operations 

The CONOPS phase was completed concurrently with the requirements analysis, 
and detailed the process by which the needs and stakeholder requirements became crafted 
around a material solution, the idea being that the only solutions that cannot be used are 
the ones that are never considered. The initial trade study listed all possible solutions that 
could have been used to meet the mission framework and requirements. With a defined 
list of possible solutions, the trade study compared each by current manufacturing 
capabilities, technology readiness levels (TRL), and subject matter expertise. This 
allowed the team to narrow down the field of possible solutions. The operational concept 
now defined the size, scope, location, and functions of the system. 

3. Requirements Analysis 

The Requirements Analysis phase was an ongoing and iterative process that 
sought to refine the piracy problem from a nebulous series of wants and issues to a 
measureable, quantifiable set of mission performance parameters. This process started 
with a formal, stakeholder-reviewed problem definition and was bound by the 
assumptions needed to define the problem. A thorough stakeholder analysis listed the 
operators, military personnel, concurrent system representatives, and contractor support. 
With stakeholder feedback, a mission scope was developed to meet the problem 
definition. 
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4. System Development 

The System Development phase of the SE process resulted in the creation of the 
OARS System Architecture. The System Architecture started to take shape as the formal 
CONOPS model, the objective hierarchy, and the functional hierarchy evolved. 

The team conducted a House of Quality (HOQ) analysis to quantify which design 
characteristics were most critical to the stakeholders. The team determined that “Detect” 
and “Track” were the most valuable design characteristic, as indicated from the 
associated weighted metrics. To gauge the effectiveness of these design characteristics 
during OARS system modeling and design, twelve Key Performance Parameters (KPPs) 
were selected from a pre-determined list of Measures of Performance (MOPs). Some of 
these KPPs included percent of pirate detection, coverage area, intercept time, and 
number of engagements. These twelve KPPs became the test metrics for system 
comparison during the modeling and simulation phase. 

After the MOPs and KPPs were defined, a functional architecture was derived to 
meet these objectives. With the functional architecture developed, the Functional 
Allocation step mapped the system’s functions to a corresponding physical element under 
the CONOPS. This resulted in the physical architecture. After the allocated architecture, 
physical architecture, and functional architecture were finalized, the overarching system 
architecture for the OARS system was defined. This system architecture was then further 
decomposed into the sub-system components of the OARS architecture. The key 
stakeholders were then consulted and their feedback was implemented back into the 
design of the OARS system. A finalized version of the OARS concept was honed in 
upon, and a process and strategy for its testing and evaluation began. 

5. System Analysis 

The System Analysis phase consisted of initial Modeling and Simulation (M&S) 
efforts, risk analysis, and cost estimation calculations. Although the overarching OARS 
system had been refined, the elements, components, and additional solutions were 
compared with these processes. During this phase, the two OARS alternatives, OARS 
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Basic and OARS Augmented, were weighed and scored against the status quo on a basis 
of mission performance, feasibility, cost, and risk. 

6. System Verification 

The System Verification process contained robust Modeling and Simulation 
scenarios from which the alternatives were modeled and analyzed further. Using the two 
identified alternatives, OARS Basic and Augmented OARS, the team built models of 
each and simulated their operations using the Naval Simulation System (NSS) software. 
Each scenario contained the same environmental modeling parameters, which consisted 
of: 355 transiting cargo vessels, 100 pirate motherships, and 200 pirate skiffs. The model 
environments spanned 390,000 square miles of ocean in the Gulf of Aden and simulated 
anti-piracy operations during a 30 day period. 

During the System Verification phase, the team focused on particular NSS data 
measurements which were relevant to original stakeholder MOEs, such as, percent of 
pirate detection, number of successful pirate attacks, and number of engagements. 


7. System Integration 

The System Integration phase of the systems engineering process defined an 
integration strategy for the OARS system. The team analyzed each subsystem that make 
up an OARS system. From there, the interoperability of each subsystem was checked 
against the other subsystems to determine if they could be integrated. This was done by 
conducting research of the subsystems and their corresponding support systems, as well 
as consulting with the subsystem’s Subject Matter Experts (SME). One example of an 
integration concern was whether or not the host vessel could support multiple UAVs, 
their launch platforms, and control stations. 

8. Recommendations 

Finally, the Recommendations phase of the systems engineering process was 
where the OARS team computed all findings from the previous phases and made 
recommendations for the most efficient and cost effective system, as well as 
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recommendations for areas of further study. Based on life cycle costs and the 
effectiveness results from the modeling and simulation analysis, the OARS team 
recommended the OARS Basic alternative to be utilized in future anti-piracy missions. 
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II. PROBLEM DEFINITION 


Focusing on the Requirements Analysis Block of the SE design process, the 
OARS team adopted a multi-objective approach for defining the best system with regard 
to stakeholder needs. The following chapter transforms the OARS team’s stakeholder 
inputs and requirements analysis effort into the CONOPS that is used as the basis of the 
system’s design. 

A. PROBLEM STATEMENT 

Global piracy has progressively increased over the last four years, significantly 
impacting maritime commerce and burdening international maritime navies. Due to 
CTF-151’s efforts of patrolling the IRTC, the piracy problem has began to spread to a 
larger ocean environment. The problem is to comprehensively survey and protect a vast 
amount of ocean. Additionally, Somali pirates are hard to identify from normal 
fishermen, so a capability needs to exist to allow for classification of pirates before they 
attack. 

The OARS system will attempt to deter piracy in a vast area of open ocean by 
providing UAV surveillance and reconnaissance. The OARS system’s UAV technology 
will attempt to classify pirates before they attack. Once pirates have been identified, the 
system should be capable of neutralizing and detaining the pirates. 

B. REQUIREMENTS ANALYSIS 

Requirements are generally considered the cornerstone of the systems engineering 
process. Originating requirements are those requirements initially established by the 
system stakeholders, with the help of the systems engineering team. Some examples of 
originating requirements for the OARS system were the requirements for capturing of 
live-video surveillance of pirate activity and the requirement that UAVs should not use 
lethal force. The systems engineering design process is a mixture of establishing 
requirements to define the design problem and portioning the physical resources of the 
system into components that perform functions that meet the requirements. Many 
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important decisions are made by the systems engineering team that will ultimately affect 
the performance of the system and the satisfaction of the stakeholders (Buede 2009). 


1. Stakeholder Analysis 

A stakeholder analysis was conducted to gain a better understanding of the needed 
capability and determine customer desires from a larger point of view, with the goal of 
addressing joint, international and naval service requirements. 

The fundamental need was framed as the next upgrade using a system approach to 
a piracy suppression mission. The team conducted stakeholder analysis to create a list of 
needs and desires from an emerging list of stakeholders. Information was gathered by 
conducting interviews via email, phone calls and telephone conferencing. The questions 
were designed to guide the stakeholder through the difficult issues the OARS team 
discovered during their research. Follow-on discussions were teleconferenced with 
willing stakeholders who offered time to discuss their needs, requirements and concerns 
regarding an OARS System. 

The OARS team was initially evaluating the use of lethal deterrence aboard the 
UAVs, but the results of the stakeholder analysis indicated that this was a bad idea as it 
would not comply with international maritime law. For this reason, the UAVs were only 
used for surveillance and reconnaissance. 

a. Stakeholders 

The stakeholders who had a vested interest were identified from the 
following groups of policy and decision-makers: Fleet Commands, users, acquisition 
agents, developers, engineering contractors and Test and Evaluation (T&E) analysts. The 
key stakeholders for this undertaking were determined to include, but are not limited to 
the following: 
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Table 2. Primary Stakeholders. 


Stakeholder 

Category 

Organization 

Name 

Title/Role 

DoD/U.S. 

United States Navy 

CAPT Richard 

Brown 

Executive Assistant to 
the Assistant Secretary 
of the Navy 


United States Navy 

LT David Cook 

Riverine Squadron Three 


Naval Postgraduate School 

David Place, CAPT 
USN Retired 

UAS Fleet Liaison 

International/Joint 

International Crime 

Service Maritime Bureau 

Cyrus Moody 

Manager 


Ohio Airships 

Robert Rist 

Engineer 


Airship Consultant 

Joe Bloggs 

Consultant 


Hawker Beechcraft 

Tim Schow 

Engineer 

UAV Industry 

Tomorrow Aerospace 

Shobhit Mehrotra 

Lead Structural and 

Control Engineer 


Aereon Corporation 

William McE. 

Miller 

President and CEO 


NRL Monterey, CA 

Dr. James Hansen 

PARS SME 


b. Fleet Commands 

The Fifth Fleet has an interest in developing a solution to the hostile 
actions of pirates directed at shipping placed under their protection. Their involvement 
with the SE process was the most influential due to the sponsor-like relationship fleet 
commands have with sponsor funding. 

c. User Representatives 

The naval vessels engaged with CTF-151 operations have been operating 
for two to three years. A Naval Ship Commanding Officer who commanded the USS 
Gettysburg during one assignment to this region provided invaluable points of view on a 
variety of issues related to user operations, such as the boarding of pirate mothership and 
the capturing of prisoners. 

A Fast Boat Commanding Officer (CO) with responsibilities to develop 
tactics for preventing hostile boardings and attacks upon commercial vessels in the 
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western Arabian Sea and Gulf of Aden provided critical resources to OARS. One point 
that he made very clear was that the early identification of pirates was very important as 
it made the boarding party much safer. This Commanding Officer had developed, 
trained, and provided logistic planning requirements that enabled inbound naval forces to 
field combat-ready forces. 

Additional stakeholder input was provided to our project by the Director 
of the Pirate Attack Risk Surface (PARS) effort at the Naval Research Lab located in 
Monterey, CA. The PARS Software is a predictive model that utilizes algorithms to try 
and predict the likelihood of an attack by pirates. Due to its classification, actual PARS 
data was not used in our Modeling and Simulation efforts. 

d. System Developers 

A number of UAV industry contacts were helpful and interested in the 
OARS effort. These stakeholders included companies such as Ohio Airships Incorporated 
(Akron, OH), Airship Consultant (Shortstown, Bedfordshire, England), Hawker 
Beechcraft Corporation (Witchita, Kansas), and Aereon Corporation (Princeton, New 
Jersey). These experienced contractors provided inputs for the interface design and 
communication strategy. One of the areas that they aided us in was how to operate 
multiple UAVs from a single host vessel. 

2. Stakeholder Feedback 

Stakeholder solicitation was accomplished by conducting surveys and interviews 
with our stakeholders, as well as researching the current solution and difficulties 
experienced in anti-piracy operations. Questions were designed to facilitate effective 
telephone interviews with stakeholders. The problem statement was formed from the 
inputs gathered from all stakeholder groups. A summary of key stakeholder inputs can 
be found in Appendix A. 
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a. Policy Makers ’ Recommendations 

Research of operations policy documents offered insight into the 
operational capability of maritime patrolling. Based in Manama, Bahrain, the Fifth Fleet 
approved and funded the current CTF-151 efforts, which are limited to the oceanic 
choke-points in the Gulf of Aden where pirate activities had been reported and observed. 
The policy guidance for the maritime effort demanded a system traceable back to the 
following naval capability requirements: 

• Forces will use multi-channel two-way C2/SA systems that protect data at 
the confidential or higher level of classification. All devices operated at 
this level that transmit and receive voice and video data will be designed 
to protect this data to a level merited by classified information. 

• Data collected from the UAV systems will allow the dual use of UHF and 
Satellite distribution networks to provide un-interrupted delivery of real¬ 
time information for on-scene commanders to conduct multi-sensor 
patrols. These patrols will conduct around the clock in all weather 
conditions to allow maximum probability of hostile detection within the 
operational area assigned. 

• Blue Force support vessels will provide additional afloat 
services as required to conduct internationally supported INTERPOL 
certificated activities. UAV units operating in an operation space will 
employ capabilities that allow assets to deploy and retrieve on a host 
vessel for the purpose of refueling and servicing multiple detection and 
data transmission equipment. 

• Blue Force Commanders will provide necessary direction to Multi-system 
operations in a coordinated manner with one Common Operational Picture 
(COP). 

b. Acquisition Agent Recommendations 

Interview responses from acquisition community members offered 
understanding about the early-milestone preferences of today’s acquisition workforce. 
The following were recommendations from the acquisition agents: 

• Develop an Initial Capability Document (ICD) for OARS. 

• Create a formal Program Objective Memorandum (POM) initiative for 
OARS. 

• Continue dialogue with the operational forces to identify evolving needs. 

• Continue socializing the concept to U. S. Navy leadership. 
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• Develop Capability Development Documents (CDDs) to identify the 
highest priority required capabilities as determined by the warfighter 
input. 


c. Clients and Users Recommendations 

Interview responses from the user community offered insight to the 
preferences of today’s solution, and provided feedback on additional capabilities desired 
by the end-user. The current force capability fielded has communication systems (secure 
and clear), recording devices for evidence collection, command and coordination chain of 
command, and gun weapon systems (major and minor caliber). Some foreign ships have 
medium caliber guns. 

The following desired capabilities were identified by the users: 

• Tracking of suspicious shipping in transit channels where Blue Cargo 
vessels pass. 

• Situational awareness of Blue Forces in the transit channels. 

• Communication connection to the OARS command center. 

• Secure and unsecure communications. 

• Logistical support plan. 

• Data sharing to support the COP. 

• Interoperability between coalition, service elements, and other agencies 
for joint missions. 

• Ruggedized equipment with enhanced durability for the different 
operational environments experienced. 

• Ease of use and ergonomics for primary search sensors. 

7. Needs Analysis 

The results of the OARS team’s research and interviews with key stakeholders 
enabled the requirements development to progress with a rich data set. However an 
independent detail analysis of the problem was needed to further constrain and define the 
problem. Every pirate attack that occurred in the Gulf of Aden during 2010 and the first 
quarter of 2011 was recorded by the ICC Piracy and Robberies report. The team 
cataloged and analyzed this data to further define the piracy problem and develop the 
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performance parameters of the system. Figure 2 shows the highlights of the team’s data 
analysis. The team derived values for the 50 th percentile and the maximum percentile for 
metrics such as; distances between pirate attacks, hours between pirate attacks, speed of 
attacks, and areas covered by the pirates. The chart illustrates the values of the distance 
between attacks and hours between attacks. It then compares the operating range 
between these attacks. The team assumed the effect to be linear and this led to the range, 
endurance, and area covered metrics. The metrics were derived to cover the majority of 
attacks in an area of 1.1 square million miles. The pie chart that is located in the lower 
left corner of Figure 2 shows the type of attacks the pirates have committed. It shows 
that all attacks occur when ships are underway. The last chart shows the number of 
attacks per season, and illustrates that the attacks are dependent on weather and sea state. 
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Figure 2. OARS Affinity Diagram. 
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8. Effective Needs Statement 

Discussions with stakeholders allowed the team to formulize a chain of events 
that must be followed by the OARS system in order to effectively counter piracy. It was 
identified that the first action that must occur is the “detection” of pirates. Once detected, 
the OARS system must maintain “tracking” of those pirates. The OARS system must 
then be able to “intercept” the pirates. And finally, the OARS system must be able to 
“neutralize” the pirates by disarming them and making arrests. The team also made the 
decision that this system would be designed to be as cost effective as possible. And do to 
the fact that the system will be operating in International waters, the system must also 
comply with International Maritime Law. 

Following a full examination of stakeholder requirements, the results of the needs 
analysis, and the OARS team’s original assumptions that were documented in Section C 
of Chapter I, the following effective needs statement was derived: 

The OARS system will economically and efficiently detect, track, intercept, and 

neutralize pirate threats across 1.1 million square miles of open ocean, within 

compliance with international maritime law. 

9. Input-Output Model 

In Figure 3 the OARS team developed a simple view of the inputs and outputs of 
the system at the top system level. This view provides a partial list of controllable and 
uncontrollable inputs and their respective outputs after the system while operating. This 
list was not all inclusive but is a partially focused set of considerations based on the 
existing CTF-151 system used today and considered essential for operations. 
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Controlled Inputs 


Expected Outputs 

♦Area of Initial Search 


♦Efficient Data Collection (Tracking) 

♦Optimum Search Space 


& Identification 

•Operation Orders 


•Criminal Activity Interdiction 

♦TTP’s 


♦Orderly Processing of Pirates and 

♦Network Interfaces for Shared Data 

Evidence 

•Ready Condition Assets, i.e., RHIBs 

•Decreased Number of Pirate 

& Support Ship Availability 


Attacks 

INPUTS 

OARS System 

OUTPUTS 



Uncontrolled Inputs 


Possible Stochastic Events 

•Environmental Conditions 


•Pirates Board Commercial Vessel 

♦Electronic Emission Conditions 


•Commercial Crew Kidnapped 

♦Hostile Red Force Tactics, 


•Commercial Crew Member Killed 

Techniques, and Practices 


♦Military Crew Member Kidnapped 

•Weather/Environment 


♦Military Crew Member Killed 

♦Communication Failures 


•Military Asset Damaged 



•Numerous Casualties Needing Aid 


Figure 3. OARS Input/Output Model 


a. Controllable Inputs: 

The operators have the ability to select one operating area in the most 
probable intercept position. The random probability of the hostile intrusion was modeled 
through the Naval Simulation System (NSS) software to forge the environment of space 
and time attached to the goal of response and prevention of boarding. 

The material requirements were in the form of seagoing systems deployed 
now for monitoring events at sea in an area of interest by U. S. Naval forces in keeping 
with common operating Tactics, Techniques and Procedures (TTPs). The physical 
boundaries of the system were supported with common maintenance approaches used by 
deployed units. 

Data sets with formatted descriptive elements, such as Operational Orders, 
were provided via common secure communications and issued by appropriate Blue Force 
Commanders. Risk mitigation plans and procedures were pre-planned to accommodate 
hazards and eventualities that were considered to challenge the integrity of primary 


21 













mission objectives. For the purposes of this project, it was assumed that these C2/SA 
devices will interface with a network capable radio/transmission device. 

Additional information systems relying on an available network capable 
system did include automated Weapons Systems Status, Individual Health Monitoring, 
and other systems reporting details relevant to the operating environment. Inputs were 
processed via networking interfaces like Universal Serial Bus (USB), Ethernet, and Serial 
ports. 


b. Uncontrollable Inputs: 

With all operational systems, the uncontrollable inputs consisted of 
networking anomalies, environmentally destructive effects, electromagnetic effects, and 
equipment failures. Our SE process considered a variety of opportunities to create 
harmful eventualities during operations, in hopes of designing so as to mitigate or prevent 
failure events. 


c. Controllable Outputs: 

Outputs were enabled via networking interfaces. As a result of timely 
communications and detection processes, the ability to develop and analyze data in a 
patrolling at-sea environment allowed naval assets to search, detect, track, and target 
contacts with a variety of on-vessel controlled sensors. Actionable information through 
visual images of ships and activities at sea in daylight and low light level periods were 
viewed and shared with a command and control center. The data sent from the system to 
a shared network provided the best picture of situational awareness that was possible 
under the mechanical, electrical and stochastic conditions. The system provided services 
in response to developed situations that demanded specialized resources like weapon 
systems on RHIBs and medical services following the use of lethal force. Additional 
services like detention and transportation of criminal suspects, seized property, and 
contraband were provided. 
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d. Uncontrollable Outputs: 

Some of the uncontrollable outputs that can have a negative effect on ship¬ 
board operations were identified as; cross-talking circuits, network interruptions, garbled 
or unreadable data, and other data elements. The system was able to overcome these 
obstacles through redundancy and sound communication procedures. The failed 
processing of data allows corrupted data to be considered as actionable data necessary to 
be placed in context and used appropriately despite error and inconsistency. The system 
was robust enough that such weakness in command and control offered opportunity to 
dismiss unreliable data. 

The IO model in Figure 3 provided the SE Team another tool that 
described the basic information flow of data and the basic functions expected within the 
communications /networks/weapons system at the top level. In other words, the team 
used the IO model to determine, “What does the system need to do?” rather than try to 
resolve ‘How does the system do it?’ The description of the system then allowed the 
team to move forward into the functional analysis. 

C. CONCEPT OF OPERATIONS (CONOPS) 

1. Current Anti-Piracy Operations (CTF-151) 

Current anti-piracy operations consist of Combined Task Force 151 (CTF-151) 
operating in the Gulf of Aden and the surrounding area. CTF-151 is comprised of a mix 
of U.S. Navy ships and coalition ships commanded by a rotating command post. The 
ships are assigned individual patrol areas that patrol the entire region on a twenty-four 
hour basis. Ships are assigned individual patrol regions which are designed to maximize 
the amount of area covered based on current information on suspected pirate activity. 
When a distress call is received, the nearest CTF-151 ship responds. When the U.S. 
Navy or coalition ship is within acceptable helicopter range, a helicopter is deployed to 
provide immediate assistance to the merchant vessel. At that time, the helicopter may 
also start to gather on-site intelligence, which is then relayed back to the commander on 
board the ship. The helicopter is not allowed to automatically engage the suspected 
pirates unless in self-defense. Helicopters are allowed to use intimidation tactics to deter 
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suspected pirates. If suspected pirates do not stop, the attack helicopter pilots are allowed 
to ask commanders for a “weapons free” order which allows them to utilize the small 
caliber machine guns to fire in front of or behind the suspected pirates for further 
intimidation tactics. When suspected pirates have stopped, RHIBs are deployed from the 
ship to capture prisoners and evidence for eventual prosecution. RHIB boats are lightly 
manned and equipped with personal small arms, although they are only utilized for self- 
defense purposes. Figure 4 shows an Operational Concept diagram of the CTF-151 
solution. Since CTF-151 is comprised of many different vessels from many different 
countries, its Operational Concept includes a plethora of naval vessels. The concept 
diagram depicts all elements involved in a CTF-151 mission including naval vessels, 
helicopters, container ships, RHIBs, and satellite communications. The background of 
the diagram is a depiction of the Gulf of Aden and Indian Ocean with markers indicating 
where acts of piracy occurred in 2010. 
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Figure 4. Operational Concept: Current Solution, CTF-151. 
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Some ships that are not equipped with a helicopter may employ an UAV that 
performs reconnaissance missions on suspected pirates. Suspected pirate motherships are 
difficult to distinguish from ordinary harmless fishing vessels and vessels containing 
people and arms with the intent of capturing unarmed merchant vessels. The UAY 
provides real-time, up-close, video surveillance of the suspected pirates. 


2. OARS CONOPS Generation 

The requirements analysis phase of the systems engineering process led the 
OARS team to develop multiple alternative systems. The stakeholders were very clear on 
the needs of the OARS anti-piracy system. These needs were focused around the 
particular need for a system that could cover a broad area of ocean, due to the fact that 
Somali Pirates are expanding their reach into the Indian Ocean and beyond. For this 
reason, the OARS team sought to create a system that utilized unmanned aerial vehicles 
(UAV) that would be launched from “host vessels” at sea. 

The purpose of the host vessel is to provide a resource from which to launch, 
recover and support the UAVs. The area of operation about the host vessel will be 
defined by the most effective and efficient use of a number of UAV craft to provide 
assistance to all vessels in peril within a reasonable time period. The sensors will detect 
and communicate video and location data such that critical tracking will have occurred in 
determining the identification of a target of interest. 

The elements of the OARS system are: Host vessel, UAVs, helicopters, satellite 
networks, pursuit vessels, and targets. The OARS system has a fixed number of UAVs 
that perform detection, surveillance, tracking, identification, and communication of data. 
These UAVs have been proven to operate well in all expected weather conditions. The 
winds are generally below 17 knots and gale winds develop in the more eastern oceanic 
areas from the Horn of Africa up to 40 knots. The temperatures were generally hot year- 
round with temperatures routinely exceeding 90 degrees. 


25 



a. Basic OARS 

The OARS Basic CONOPS model includes a ship capable of supporting 
multiple swarms of UAV operations, armed helicopter operations, all net-centric C4I 
requirements, brig capabilities for transportation of captured pirates, as well as weapons 
for self-defense. Pursuit vessels are also required to capture pirates once they have been 
detected. Figure 5 represents an Operational Concept diagram for OARS Basic. The 
green radar circles represent individual search area range. 



Container ship 


Figure 5. Operational Concept: OARS Basic. 

As mentioned in Chapter 1 of this report, the OARS team focused on 
protecting the entire Gulf of Aden from piracy. For this reason, six individual OARS 
Basic systems will be strategically placed in the Gulf of Aden. Figure 6 illustrates the 
area of coverage that would be achieved by six Basic OARS systems. 
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Figure 6. Six OARS Basic Systems Placed Within the Gulf of Aden. 
b. Augmented OARS 

The last CONOPS option includes everything from the Basic OARS 
model, plus an augmentation using a high altitude long range airship such as the Broad 
Area Maritime Surveillance (BAMS) UAV. This will supplement the coverage area 
provided by the Basic OARS model which uses much slower ship-launched UAVs. The 
BAMS UAVs will be land-based and located wherever the OARS commander deems 
necessary based to the perceived threat. The Augmented OARS Operational Concept 
diagram is shown in Figure 7. 


27 











Host Vessel 


Container ship 


Figure 7. Operational Concept: OARS Augmented. 

Just as with the Basic OARS CONOPS, the Augmented OARS CONOPS 
will also feature six identical OARS systems to allow for complete coverage of the Gulf 
of Aden transit corridors. Figure 8 illustrates the area of coverage that would be achieved 
by utilizing six Augmented OARS Systems in the Gulf of Aden. The large oval-shaped 
area that is colored “green” on the figure illustrates the added search pattern that would 
be gained from the BAMS UAV or Airship. 
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Figure 8. Six Augmented OARS Systems Placed Within the Gulf of Aden. 
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III. DESIGN 


The Design and Analysis of the OARS system provides a solution space for the 
problem definition, primitive needs, refined requirements, and stakeholder’s interest. It 
combines elements of the Requirements Analysis, System Development, and System 
Analysis stage of the System Engineering process. It also helps to develop the inputs and 
alternatives for the modeling and simulation needed for the final result. The Design and 
Analysis stage begins with the system requirements and refines the customer needs 
through the House of Quality (HOQ). It maps the requirements through the functional 
analysis into a possible architecture. With the elements of the architecture known, sub¬ 
system alternatives are generated and screened by feasibility. It then details 
recommended alternatives for the modeling and simulation (Blanchard and Fabrycky 
2006, Ch. 2 and 3). 

A. SYSTEM REQUIREMENTS 

The system requirements are the actions and processes that the OARS system is to 
complete, which are usually articulated in “shall” statements. They are divided into two 
separate groups, functional and non-functional requirements. The Functional 
Requirements are the requirements that the OARS system is to complete by performing 
the functions and actions necessary to solve the problem definition and mitigate pirate 
threats within its context boundary. The Non-functional requirements are those 
requirements that support the completion of the functional requirements. These included 
the suitability requirements, such as reliability, maintainability, and usability. 

1. Functional Requirements 

The functional requirements are the actions and functions that the OARS system 
must carry out to deter piracy and protect shipping in its area of operation. As defined by 
the effective needs statement, the OARS system must detect, track, intercept, and 
neutralize threats within compliance of maritime law. In order to accomplish this, the 
OARS system must carry out a mission defined by the mission’s functions. These 
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mission functions are to start a mission, patrol an area, communicate, engage hostiles if 
detected, and finally, to return to port when the mission is complete. These functions are 
illustrated in Figure 9. 
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Figure 9. OARS Mission Profile. 


Each of these mission functional requirements are needed to complete an OARS 
mission. The team created these mission functions to simplify the OARS mission profile, 
while still keeping in mind the needs of the OARS system. Table 3 shows how the needs 
statement, which was derived in Chapter II, correlates to the OARS mission profile. 
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Table 3. Needs Statement Mapping to Mission Functions. 


Need 

Statement 

Functions 

Mission 

Start 

Patrol 

Communicate 

Engage 

Ho stiles 

Mission 

End 

Detect 

X 

X 

X 



Track 

X 

X 

X 



Intercept 


X 

X 

X 


Neutralize 



X 

X 


Within 

Compliance 

X 

X 

X 

X 

X 


The Mission Start function detailed all aspects of preparation, logistics, and 
movement to place the OARS system in the theater of operation. The Patrol aspect of the 
mission included the actions required to patrol an area of suspected pirate activity, 
including the Detect, Track, and Intercept functions. The Communicate function 
encompasses all communication efforts between the OARS system and allied vessels, 
friendly cargo vessels, UAVs, etc. On encounter with a group of pirates, the Engage 
Hostile requirement included all of the requirements needed to intercept and neutralize 
hostile targets. Once the mission has been completed, the Mission End aspect covered all 
the actions needed to return the assets and personnel to their home stations and prepare 
the physical systems for the next deployment required to fulfill the functions previously 
stated. These top level functions were developed to meet the objective requirements and 
were traced down to the performance parameters needed to carry out the mission. 

2. Non-Functional Requirements 

The Non-Functional Requirements are all the requirements necessary for 
continued operations of the OARS system as it carries out its mission. Non-functional 
requirements are the mission critical requirements that cannot be deduced from direct 

examination of the piracy threat but are inherent in the system. For example, the 
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reliability of the system helps to determine the operational availability of the sub¬ 
systems. This also helps to determine the required number of critical spares and the 
number of OARS systems that are actually needed. The Human Factors requirement of 
the system determines the operational man power requirements and determines the crew 
sizing per each OARS system. These non-functional requirements are typically found 
using “bottom-up analysis” techniques, which are techniques of tracing the requirements 
backwards after the system has been developed. Because the OARS team focused on 
UAV technology in the deterrence of piracy, the non-functional requirements were 
addressed briefly by the team in a top-level analysis, leaving these particular 
requirements as an area for future research. 

B. OBJECTIVE REQUIREMENTS 

1. Measures of Effectiveness (MOE) 

The objective requirements, which consist of Detect, Track, Intercept, Neutralize, 
and Compliance with international maritime law, are broken down into function layers 
and are ultimately transformed into the system’s physical architecture. The customer 
needs are based on a modified kill chain used by U.S. Military forces. The top-level of 
the OARS system included Detect, Track, Intercept, Neutralize, and Comply with 
international maritime law. The Detect stage was critical since this has been a continuing 
problem in anti-piracy operations. Often it is not until the pirates have engaged a neutral 
target that they are even considered suspicious. Once a possible pirate target has been 
found, the OARS system had to track the target to determine its course and its intention. 
The stakeholders have stated that finding sufficient evidence to prosecute the pirates 
remains a high priority for the system. 

The next function of the OARS system was to intercept, or cause interception of 
the threat. This will force the adversary to reconsider their actions or ultimately be 
arrested. The last function was to neutralize the pirate threats. This could be 
accomplished through detaining the pirates, showing force, or the actual use of this force. 
All the functions must be conducted within the scope of maritime law, within the 
boundaries of a basic regard for the human rights of the pirates, as well as the norms and 
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regulations found in the Geneva Convention and the Uniform Code of Military Justice. 
Below these five top-level functional requirements, the detailed functions of the system 
fully define the mission and what actions need to take place to fulfill it. The customer’s 
needs are mapped to the objective requirements. These are then met by the functions of 
the systems, which are mapped to the physical architecture and computed into a 
measureable aspect by the Measures of Effectiveness (MOE). The MOEs are then 
derived from a physical metric by the performance parameters. To meet the performance 
parameters, the derived requirements are found to determine the physical needs and 
requirements of the system. Since the OARS Capstone project was a top-level effort, the 
derived requirements from the performance parameters were not calculated. 

To ensure that the requirements flow-down was within line with stakeholder 
expectations and to make sure that the key requirements were properly weighted, an 
Analytic Hierarchy Process (AHP) was used to assign customer preference to the 
appropriate functions. This was the start of the Quality Function Deployment (QFD) 
Analysis (Buede 2009, Ch. 6). 

C. QUALITY FUNCTION DEPLOYMENT (QFD) 

The QFD aids the stakeholder in assuring that the most critical requirement 
receives the greatest consideration. Design is a balance of compromises between 
competing goals. QFD assures that the stakeholder’s goals and the system’s strengths are 
aligned. The first step is to weigh the stakeholder’s needs against one another in order to 
highlight the greatest needs. The OARS mission statement is to economically and 
efficiently detect, track, intercept and neutralize pirate threats across 1.1 million square 
miles of Open Ocean, within compliance with International Maritime Law. Each of these 
needs are dependent upon each other and critical to the mission statement. Figure 10 
shows which mission aspects were most critical in the eyes of the stakeholders. The 
strongest relationship among the needs of the OARS system was the relationship between 
Detect and Intercept (Blanchard and Fabrycky 2006, Ch. 3). 
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Figure 10. Preference Weights of the Stakeholder’s Needs. 


The QFD process was implemented through a series of interconnecting HOQ 
matrices. This portion of the process begins by listing the customer needs down the left 
side of a matrix, as shown in the left-most rows of the AHP in Figure 11. After the 
customer’s needs were listed, their corresponding rankings are then listed in the next 
column to the right. These rows are collectively referred to as the WHATS of the HOQ. 
The columns are the technical response of the designer and are commonly referred to as 
the HOWS of the HOQ. The HOWS are the functions for the OARS system. 
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Functions (Hows) 


Customer Needs (Whats) 

Mission Start 

Patrol 

Communicate 

Engage 

End Mission 






Detect 

0.3723 

0.3723 

3 

9 

3 

3 


Track 

0.1489 

0.1489 

9 

9 

9 



Intercept Pirates 

0.2482 

0.2482 


3 

3 


9 

Neutralize Threats 

0.1241 

0.1241 



3 

9 


Within Compliance with maritme law 

0.1064 

0.1064 


3 


3 

3 

Check Sum 

1.0000 

1.00 



Weighted Performance 
Percent Performance 


2.5 

5.8 

3.6 

2.6 

2.6 

16.9 

0.145 

0.341 

0.212 

0.151 

0.151 

1.000 



Figure 11. The “What’s” versus the “How’s” portion of the HOQ. 


The Functions, which were introduced in the beginning of Chapter III, included 
Mission Start, Patrol, Communicate, Engage, and End Mission. The original 
stakeholder’s weights and driving weights from the original AHP diagram drove OARS 
to be a primarily patrol based system. This was one of the leading requirements that 
caused OARS to rely heavily on Unmanned Aerial Support (UAS) systems and extended 
range mission profiles. Both Mission Start and Patrol, from the field of functions, 
received high marks on the matrix shown in Figure 11. This matrix starts to translate the 
OARS system’s functions into the system physical architecture. These were the start of 
the design characteristics that were used to define the physical structure of the system. 
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The following HOQ matrix, Figure 12, is the matrix between Functions and Design 
Characteristics. 


System Components 


Functions 

UAS System 

Host Vesel 

Pursuit Vessel 

In Theater Command and 
Control 

Fleet Ships 






Mission Start 

0.1760 

0.1760 

3 

3 




Patrol 

0.3626 

0.3626 

9 

9 

3 



Communicate 

0.2146 

0.2146 

9 

3 

9 


9 

Enqage 

0.1322 

0.1322 


3 


9 

9 

End Mission 

0.1147 

0.1147 


3 



6 

Check Sum 

1.0000 

1 00 



Weighted Performance 
Percent Performance 


5.7 

5.2 

3.0 

1.2 

3.8 

189 

0.303 

0.274 

0.160 

0.063 

0.201 

1.000 



Check 


Figure 12. The Functions versus Design Components of the HOQ. 


The Design Components were developed to reflect a flexible architecture needed 
to effectively meet the system functions. By meeting the system’s functions, OARS 
attempted to address the stakeholder’s needs and expectations. After completing an 
initial trade study on a top level element, the top level components were selected. The 
top level systems were based on feedback from stakeholders and industry representatives’ 
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interviews and were chosen to allow flexibility for further analysis. The design 
components included a UAS system, a host vessel, a pursuit vessel, in theater command 
and control, and fleet ships. The UAS system consisted of all elements needed to support 
an unmanned aerial system. The UAS responsibility was to fulfill the primary functions 
of Detect and Communicate, and fulfill the driving objectives of Detect and Track pirate 
activities. The second most important element of the OARS system was the host vessel. 
The host vessel would act as the launch and recovery platform, detaining center, mobile 
base of operations for the UAS system, and pursuit vessel. The pursuit vessel was a 
system element designed to perform the Engage function and fulfill the objectives of 
Intercept and Neutralize pirate activities. The last two elements consisted of fleet ships 
and in-theater command and control. These two reflect the OARS system’s primary role 
as a subset of a system of systems already in place. OARS was designed to seamlessly 
integrate with the multinational fleet in the area, to operate under possible command and 
control, and to work with American and allied shipping and fleet assets in the area. 

Once the physical architecture was defined, the performances of the physical 
elements were compared to the desired target values using the MOEs. The MOEs were 
built in a manner so that they trace back to the objectives of the system. This ensures a 
mapping between the objective requirements and the measurable quantities. The MOEs 
were Detect, Classify, Track, Intercept, Neutralize and Communicate. These MOEs 
allowed for the direct measurement and comparison of the system and allowed for the 
rapid development of the performance parameters. The “Detect” MOE encompassed all 
aspects of detection and surveillance. The “Classify” MOE included all attributes from 
vessel databases to personnel decisions that were used to assess the hostility of a vessel. 
The “Track” MOE covered the system’s capacity to monitor a vessel once it was 
determined to be suspect. The “Intercept” MOE, which had the lowest score of the 
MOE’s, reflected the system’s ability to match headings and velocities of the target 
vessels. The “Neutralize” MOE measured the OARS system’s capability to reduce the 
known threats and make them inoperable or unable to carry out their intended role. 
Lastly, the “Communicate” MOE measured the systems capability to interface with both 
operational forces and with neutral shipping vessels. From these stakeholder weightings 
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and priorities, the KPPs could be selected from the list of derived performance 
parameters. These were then directly linked through the physical architecture through to 
the functions of the OARS system and were used to aid in the definition of the functional 
allocation. Table 4 shows the OARS KPPs. 


Table 4. OARS System Key Performance Parameters (KPPs). 


KPPs 

Units of 
Measure 

Threshold 

Objective 

Source 

Percent of Detections 

Probability 

75% 

100% 

Derived from Anti-Piracy Study 

Area Covered 

Square nautical 
miles 

390,000 

1,100,000 

Derived from Anti-Piracy Study 

Sea State Operable 

Beauford scale 

2 

5 

Derived from Anti-Piracy Study 

Targets Engaged 

Number 

1 

10 

Derived from Anti-Piracy Study 

Number of Tracks 

Number 

1 

10 

Derived from Anti-Piracy Study 

Time to Intercept 

Minutes 

24 

16 

Derived from Anti-Piracy Study 

Number of 

Engagements 

Number 

1 

10 

Derived from Anti-Piracy Study 

Number of 

Neutralizations 

Number 

1 

10 

Derived from Anti-Piracy Study 

Safe Transit 

% of ships to 
safely transit 

98% 

100% 

Stakeholder Requirement 

Number of Prisoners 

Brig capacity 

4 

20 

Stakeholder Requirement 

Range of 

Communication 

Miles 

100 

500 

Derived from Anti-Piracy Study 


The KPPs column shows a listing of the different KPPs. Following these are the 
units of measure. The KPPs are bound by the threshold and objective values. The 
threshold value was defined as the minimum required value for the OARS system to be 
operationally effective. The objective was the value that once exceeded, would not 
provide any further benefit to the system. The source column lists where the data was 
originally found. A detailed study of each attack in FY 10 through the first quarter of 
FY 11 revealed what values the OARS system needed to meet to respond to the pirate 
threats in and around the Gulf of Aden (ICC Pirate Attack Report 2010-2011). With the 
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threshold and objective values set, the following KPPs were determined to reflect the 
refinements of the need to deter piracy. 

• The Percent of Detection attribute is the probability of sifting out a pirate 
threat from the background maritime traffic in the area. It reflected the 
success rate of finding a pirate threat in a given area. 

• The Area Covered attribute was the square mileage of ocean that was 
needed to be covered to stop a pirate threat from operating in a given 
theater. 

• The Sea State Operable attribute reflects the need for the OARS system to 
operate in the same conditions that the pirates are willing to tolerate. 

• The Targets Engaged attribute reflect the number of skiffs and pirate 
vessels that could be independently engaged at one time during an 
operation. 

• The Time to Intercept attribute was determined from the typical response 
time for current assets to respond to a vessel under threat. 

• The Number of Engagements attribute reflects the number of independent 
operations the OARS system could conduct simultaneously. 

• The Number of Neutralizations attribute reflects the number of targets 
engaged and neutralized, whether by lethal or non-lethal force. 

• The Safe Transit attribute is the percentage of shipping vessels that the 
OARS system could guarantee safe passage through troubled seaways 
without incident. 

• The Number of Prisoners attribute reflects the holding capacity of the 
OARS system while it is in operation. This is a critical aspect that is 
missing from the current CTF-151 system, since captured prisoners are 
forced to bunk in crew quarters until processed. 

• The Range of Communication attribute determines the OARS system’s 
capability to communicate with its own deployed UAS systems and all 
neutral or friendly forces in the area. 


With these quantities known, the system development process allowed for 
iteration and inputs into the modeling and simulation field. This allowed the OARS team 
to quickly and efficiently compare competing solutions to the OARS mission profile. 
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D. ARCHITECTURE 

After the OARS system’s MOEs and KPPs were developed, the team then 
focused its attention on creating the architecture of the system. Developing the System 
Architecture is cornerstone in the system’s engineering process and aids in the 
fundamental development of the system. The overall System Architecture is decomposed 
into three core sections, which consist of Functional Architecture, Physical Architecture, 
and Allocated Architecture. The Functional Architecture defines what the system must 
do. The Physical Architecture represents the partitioning of physical resources available 
to perform the system’s functions (Buede 2009, pg 27). The Allocated Architecture is the 
mapping of the functions to resources or physical components. Allocated Architecture 
indicates the interfaces and data flow between systems or functions. This will be 
explained in Chapter III, Section 3, Allocated Architecture, through the use of an 
Integrated Definition for Function Modeling (IDEFO). 

Each of the three architectural building blocks were detailed and outlined using 
CORE® 7, from Vitech Corporation. This tool provided a solution for managing and 
tracking requirements, building Functional-Physical Architectures, and simulating 
functional flow. It also allowed the team to create relationships and interfaces between 
elements to outline the Allocated Architecture, while allowing for configuration 
management of these architectural baselines. A summary of CORE® 7’s element 
relationship schema is shown in Figure 13. The elements of the diagram labeled as Item, 
Function, and Component, were the only elements configured into the baseline of the 
OARS system. However, all elements contributed to describing the overall System 
Architecture. 
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Figure 13. CORE® 7 System Engineering Element Diagram (from Vitech 

Tutorial 7. Pg 3) 


1. FUNCTIONAL ARCHITECTURE 
a. Functional Analysis 

The Functional Analysis was developed to describe the functional 
requirements of the system and outline all that the system must do to complete its 
mission. This analysis also helped to identify basic internal and external functional 
interfaces, while aiding in the decomposition of upper-level functions. The analysis also 
aided in determining fundamental sequencing of these upper-level functions. 

After analysis of current anti-piracy efforts (CTF-151) and collaboration 
with stakeholders, initial development of the Functional Hierarchy was completed. 
Figure 14 shows the top-level hierarchy of the key OARS functions that resulted from the 
Functional Analysis. These functions were grouped into distinct sequential operations, 
labeled as Detect, Fix/Classify, Track, Intercept, Neutralize Threat, and Communicate. 
In general, the OARS system will first detect a vessel. The OARS system will then work 
to identify the vessel and assess the risk of that vessel causing harm to another vessel. 
The OARS system will then begin to track that vessel. If triggered, OARS will then 
intercept a suspicious vessel and neutralize it. Throughout the process of these functions. 
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OARS will maintain multiple levels of communication internally and externally to its 
environment. A formal Functional Hierarchy was modeled in CORE where each 
function and sub-function is detailed in the subsequent section. 



Figure 14. Stakeholder Functional Analysis 


b. Functional Hierarchy 

Using Figure 14, the Functional Analysis that evolved from the 
stakeholder’s needs analysis, the team continued on in developing a formal Functional 
Hierarchy. This was developed using a combination of stakeholder input, team 
knowledge, current CTF-151 operational analysis, and the functional requirements of the 
system. The Functional Hierarchy was modified multiple times as the overall baseline 
was developed and functional deficiencies were revealed in the system architecture. 
Detect, Fix/Classify, Assess Risk, and Track, were combined in a functional area 
renamed as Patrol. Neutralize and Intercept were combined into the functional area of 
Engage. Mission Start and Mission End are functional areas that were added to indicate 
non-mission critical functions that are required for complete mission fulfillment. 
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Figure 15, Functional Hierarchy, is the formal organized tree developed 
from the Stakeholder Functional Analysis. Some functions were renamed, reclassified, or 
divided into sub-functions, which evolved throughout the architecture process. The five 
major functional areas (outlined in red) are decomposed into sub-functions (outlined in 
orange). Specific operational details of each sub-function are also indicated on the tree. 
Complete descriptions of the operational details are outlined in Chapter III, Section 3, 
Allocated Architecture. 
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Figure 15. OARS Functional Hierarchy 
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2. Functional Flow Block Diagram (FFBD) 

The Functional Flow Block Diagram (FFBD) is another way of organizing the 
elements of the Functional Architecture. After detailing most of the functions required 
by OARS, the flow and sequence of each was described since the Functional Hierarchy 
does not capture sequencing. Since the architecting process was iterative, some functions 
were added and others were reorganized. Outlining the functional flow helped to 
recognize gaps and deficiencies in the functional design. The FFBD also indicates 
recursive functions and functions that are conducted simultaneously. The flow of each 
function is described in detail from the Top Level (Level 1) down to the decomposed 
sub-function levels (Level 2 & 3). 

a. Level 1 FFBD - OARS Mission Level 
As outlined previously in the Functional Hierarchy, OARS has five main 
mission functions: Mission Start, Patrol, Engage Hostile, Communicate, and Mission 
End. After starting its mission, the OARS system begins patrolling an area and 
maintaining vital communication with external and internal systems. If hostile activity is 
found, the OARS system will be invoked to engage that hostility. This process repeats 
itself until mission orders are given to end the mission. The mission level functionality is 
then completed. Each of these five functions will be explained in detail. However, the 
third-level FFBD breakdowns are included in Appendix B. 

The flow of each function is shown in Figure 16. It must be noted that the 
annotations at the bottom of each box are actual top-level components that are mapped to 
the corresponding function. This is part of the Allocated Architecture, which is further 
explained in Chapter III, Section 3, Allocated Architecture. 
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Figure 16. Top Level FFBD for the OARS System. 
b. Level 2 FFBD -1 Mission Start 

Figure 17 illustrates that the first step of Mission Start is to leave home 
port. It will transit to its intended destination as outlined in its orders. If needed, the 
OARS system conducts an Underway Replenishment (UNREP) to refill fuel, supplies, 
and ammunition. It then arrives at the intended operational area and checks in with the 
area commander. 



Figure 17. FFBD 1.0, ‘Mission Start.’ 
c. Level 2 FFBD - 2 Patrol 

After completing the Mission Start, OARS patrols its assigned area and 
conducts surveillance. This can be seen in Figure 18 within the area that is encompassed 
by the blue-dotted line. Patrolling includes everything except formal engagement. 
OARS must first detect a vessel before it can classify it and conduct a risk assessment. If 
the risk assessment is high, then OARS will maintain track of that vessel or vessels. It 
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continues to detect and classify vessels as incoming observations continue. The Patrol 
function cycles throughout the mission until it is invoked to end the mission. 



Figure 18. FFBD 2.0, ‘Patrol.’ 

d. Level 2 FFBD - 3 Communicate 

Figure 19 shows the simultaneous communication functions performed by 
OARS. Communicating externally includes sharing the following with ally units: a 
Common Operating Picture (COP), Pirate Attack Risk Surface (PARS) data, and other 
intelligence. Communicating externally also includes notifying the fleet of hostile 
situations. 

Communicating internally includes receiving UAY reconnaissance data, 
intercepting pirate communication channels, and exchanging information between the 
individual systems that comprise the overarching OARS system. Note how the 
Communication function is repeated throughout the cycle. It is conducted throughout 
both Patrol and Engagement functions. 
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Figure 19. FFBD 3.0, ‘Communicate.’ 
e. Level 2 FFBD - 4 Engage Hostile Activity 

While conducting a patrol, OARS may be invoked to intercept and 
neutralize a hostile vessel as indicated in the functional flow of Figure 20. This function 
involves assessing the risk of the situation, deploying the pursuit vessel, and deterring 
and/or boarding the hostile vessel to ascertain acts of piracy. At this time, arrests may be 
made and evidence may be collected. This function is also referred to as a VBSS (Visit, 
Board, Search, and Seizure). If the hostile vessel is seen as having a high level of risk, it 
is immobilized or destroyed to nullify an escalating situation. Prisoners and evidence are 
handed over to local authorities. It was emphasized by stakeholders that the OARS 
system must obtain video evidence, as this is the strongest anti-piracy weapon in theater. 
After completion of engagement, OARS continues its mission of Patrol and Engagement. 
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Figure 20. FFBD 4.0, ‘Engage Hostile Activity.’ 

/. Level 2 FFBD - 5 Mission End 

When invoked by Mission Orders to end the mission, OARS discontinues 
its Patrol and Engagement functions. OARS first retrieves its UAVs, checks out with its 
commander, and then returns to its homeport. This is shown in Figure 21. 



2. PHYSICAL ARCHITECTURE 

The generic Physical Architecture detailed the components and resources 
assigned to build a physically operating system. Stakeholder feedback and the OARS 
team’s informal feasibility analysis were both incorporated into the design of the Physical 
Architecture. The Physical Architecture was developed in parallel with the Functional 
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Architecture. As the system functions were elaborated, the physical systems needed to 
satisfy these functions were specified. Technology Readiness Levels (TRL) were also 
considered in the generation process. The Physical Architecture has many uses, 
including aiding in the design of the Work Breakdown Structure (WBS) and aiding in the 
generation of alternatives which is further explained in Chapter III, Section E, Alternative 
Generation. 

The majority of the components and systems used by OARS have already been 
successfully fielded in today’s Navy. These components include Littoral Combat Ships 
(LCS), RHIBs, and navigation systems. Some components may either currently already 
be developing systems with high TRLs or would require further development in order to 
obtain higher TRLs. Developmental systems like these would include UAV launch & 
recovery systems for multiple UAVs, or additional storage systems for 
contraband/evidence or detainees. The system is designed to easily incorporate the use of 
additional reconnaissance systems such as Broad Area Maritime Surveillance System 
(BAMS) or augmented reconnaissance airships, which are not listed as a part of this 
architecture. 

Referring to Figure 22, the system is broken into two sections: Internal OARS 
Systems (A.l) and External Support Systems (A.2). The External Support System is a 
grouping of physical systems external to the OARS system that help to satisfy some of 
the functions needed for a successful OARS mission. As stated in the background of the 
problem, the Anti-Piracy effort in the Gulf of Aden includes foreign navies, thus OARS 
must include them as a part of its operation. These external support systems are primarily 
involved during engagement with hostile vessels. 

Internal Systems are decomposed into the Host Vessel, Pursuit Vessel, and 

Unmanned Aircraft Systems (UAS). The lighter-blue boxes are the sub-systems of each 

individual system, which may be further decomposed into components. The UAS 

System includes the UAV and its launch & recovery system. The Pursuit Vessel consists 

of a RHIB boat or SH-60 Sea Hawk Helicopter, depending on the situation, capabilities 

of the Host Vessel, and the mission requirements. The Host Vessel contains the majority 

of the OARS components. In addition to the standard operating equipment contained on 
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a LCS or DDG ship, the Host Vessel also contains multiple UAS control stations and 
additional storage areas for evidence, contraband, and detainees until they are 
relinquished to authorities. 

The next section, Allocated Architecture, is where the Functional and Physical 
Architectures come together. The functions in Figure 15 are satisfied by the sub-systems 
in Figure 22. The interactions and details of each sub-system are fully discussed in that 
section. 
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Figure 22. OARS Physical Hierarchy, 

54 



































































































































3. ALLOCATED ARCHITECTURE 

Development of the Allocated Architecture is a system engineering activity in 
which the entire process comes together (Buede 2009, pg 84). It integrates the 
requirements with the Functional and Physical Architectures. According to Buede, the 
Allocated Architecture is associated with five major development activities which 
include: 

• Trace system-wide requirements to system and derive component-wide 
requirements. 

• Define and analyze functional activation and control structure. 

• Conduct performance and risk analysis. 

• Document architectures and obtain approval. 

• Document subsystem specifications. 

Reflecting on the OARS methodology, some of these developmental activities 
were done independently of the Allocated Architecture process. Performance and Risk 
Analysis were conducted early in the design process during the generation of the 
CONOPS. Information from this analysis was then directly incorporated into the 
generation of the Physical Architecture. 

System and component-wide requirements were developed in Chapter III, Section 
A, System Requirements. Stated as a functional requirement in Section A, “The OARS 
System must Detect, Track, Engage, Neutralize Targets, Provide Safe Transit, and 
Comply with international maritime law.” A physical requirement mandates the use of 
UAVs that are capable of conducting surveillance by capturing live-video. These 
requirements are traced to corresponding functions, indicating their satisfaction by the 
way of functions and physical components. This is a part of the Allocated Architecture, 
but is not explicitly detailed in this section. 

As mentioned earlier, the Functional and Physical Architectures were managed 
using the software program, CORE® 7. These architecture baselines were installed into 
the program to allow proper organization and traceability documentation. The Functional 
and Physical Architectures were mapped together to produce the Allocated Architecture. 
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Stakeholders were presented fundamental descriptions of the architectures and concurred 
with its design. 

The team created IDEFO diagrams using CORE® 7. IDEFO diagrams indicate 
interfaces, data flow, information, physical items, system control, and functional control, 
all while highlighting the physical systems that satisfy each functional activity. IDEFO 
depictions highlighted any misallocations and deficiencies in the operation. They may 
also be reviewed for necessary input and output operations. The involved functions were 
organized into a step-like fashion down and to the right with ample control triggers, 
feedback loops, and input/output arrows. Functions, which are labeled in red, are 
referred to as “Elements.” Physical systems, which are labeled in blue, are referred to as 
‘Components.’ Physical items, data, and information are referred to as ‘Items.’ Items are 
the black arrows which represent the flow of data, information, or physical items. They 
may be either inputs or outputs to a function, and they may also be responsible for the 
control of each function or sub-function. In the following section, each top-level function 
of the Functional Hierarchy is outlined in detail, including its sub-functions. 

a. Level 1 IDEFO - OARS Mission Level 

Figure 23 shows that a typical OARS mission starts with the Mission Start 
function, which is first invoked by Mission Orders. Although Mission Orders is a trigger 
and manipulates the functionality of certain functions, it also contains data which is fed 
as inputs to the Mission Start and Patrol functions. Once Mission Start is enabled, OARS 
will depart port, complete an UNREP, and transit to its operating area before checking 
into Fleet Command. This function is satisfied by the Host Vessel. 
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After check-in, a Patrol Request is made to start surveillance routines. 
This includes detecting vessels, classifying them, assessing their risk, and tracking them. 
In particular, surveillance is directed towards Suspicious Vessels that have either been 
identified by civilian vessels, or that have been identified by the OARS UAVs as having 
pirate paraphernalia (i.e. ladders, drums of fuel, etc.). Physical Systems involved with 
Patrol are the Host Vessel, UAS Host Platform, UAV System and the Host Vessel’s 
Transportation/Propulsion System. Patrolling areas are determined based on Mission 
Orders and external Fleet Surveillance Data. 

Fleet Surveillance Data that is fed into Patrol, originates from external 
communication with the fleet and other vessels. The Communicate function 
encompasses all internal and external communication for the OARS system. Externally, 
OARS communicates with the Fleet, Commercial/Private Vessels, and other Nation 
States or allies that are collaboratively operating in the area. Internally, Communicate 
includes communication with both the OARS’s UAVs and Pursuit Vessels, as well as the 
sharing of surveillance data. Additionally, it receives information from the Patrol and 
Engage functions. It communicates its Engagement Status with suspicious vessels and 
receives Contact Risk Assessment data from its Patrolling function. Physical Systems 
involved with Communicating are the Host Vessel, Pursuit Vessel, UAV System, 
Command & Control, and External Support Systems such as CTF-151 or allies. 
Communicate functions are controlled by the Mission Orders, which dictates how it 
communicates and with whom. 

OARS may receive information about hostile situations from its patrol or 

communication with the fleet and civilian vessels. If the hostile situation involves the 

hijacking of a civilian vessel, then OARS sends outs a Request Special Operations 

command for an external Special Forces team to intervene. If OARS is instructed to 

intervene upon a particular hostile situation, an Engage Hostile Request is initiated. This 

triggers the function, Engage Hostile Activity. Contact Identification Data and Risk 

Assessment Data are fed into this function from Patrol. Civilian Vessels and Suspicious 

Vessels interact with this engagement. OARS will first attempt to intercept the vessel 

and stabilize the situation. If not, then it proceeds to neutralize the hostile vessel. A 
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VBSS is conducted, which may result in arrests of Pirates and collection of Pirate 
Evidence related to the incident. Pirates and associated evidence are transferred to 
appropriate authorities for prosecution. The Host Vessel, Pursuit Vessel and UAS 
System are the physical OARS systems involved in this function. The Engagement 
Status is continually communicated internally and to other external fleet vessels. As 
discussed earlier regarding functional flow, OARS will return to Patrolling or end its 
mission after completion of Engaging Hostile Activity. 

When a typical OARS mission ends, the determination is controlled by the 
Mission Orders. Mission End includes retrieving UAVS, checking-out with the fleet 
command, completing an Underway Replenishment (UNREP), and transiting back to the 
homeport. These functions are satisfied by the Host Vessel and Pursuit Vessel, which 
conclude a complete OARS Mission. 

b. Level 2IDEFO -1 Mission Start 

The start of a typical OARS mission does not vary extensively from a 
typical USN DDG or LCS’s mission start, as the initial platform for OARS is derived 
from these vessels. To begin a mission, Mission Start functions are first initiated by a 
request to leave port, generated by Mission Orders. After the vessel leaves port, UNREP 
functions are initiated. Crew members are assigned to their tasks, and UAS supplies, 
fuel, and ammunition are loaded to the OARS system or depleted supplies are 
replenished. After UNREP is reported complete, the OARS system will continue onto its 
operational area. After arriving at its operational area, the Host Vessel checks-in with 
Fleet Command, receives its current orders, and then initiates its patrol. Figure 24 
outlines the physical systems involved and the control of each function. 
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Figure 24. IDEFO 1.0, ‘Mission Start.’ 


c. Level 2 IDEFO - 2 Patrol 

The Patrol function is the largest set of operations conducted by OARS. 
In involves Detecting, Classifying, Assessing Risk, and Tracking. Each of these sub¬ 
functions involves detailed operations and interfaces with other OARS functions. 

As mentioned previously in the Mission Level diagram of Figure 23, the 
Patrol function receives Mission Orders and external Fleet Surveillance Data while 
interacting with pirates. The Patrol function is performed by the Host Vessel and UAS 
System. To other functions, the Patrol function must output Contact Identification Data 
which is coupled with a Contact Risk Assessment of anything it identifies within its 
Patrol. 
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The Patrol function first starts with Detect. Request Surveillance starts the 
process while Fleet Surveillance is fed into it to help determine surveillance plans. A 
pattern of UAVs are launched into the assigned operational area, and surveillance is 
conducted through radar, IR/FLIR, and the interpretation of video or visual data. The 
UAV Sensors, Ship-Based Control unit, and ship’s Combat Sensor System participate in 
this function. Raw OARS surveillance data is fed into the Tracking and Fix/Classify 
functions. Contact Identification Data is a specific vessel profile which contains 
identification data, risk assessment, surveillance data, tracking data, and vessel history. 

Fix/Classify strictly involves identifying vessels and tagging them each 
with a unique identifier for tracking purposes. Differentiating suspected pirates from 
local civilians has posed the largest problem for the anti-piracy efforts. Classifying each 
vessel properly is a critical requirement of this function: hence there are many systems 
involved in determining classification. Information retrieved from the UAV is combined 
with information from the ship and fleet to identify vessels. These inputs are surveillance 
data and tracking information. Once a contact is classified, the Risk Assessment function 
is triggered to determine the risk of a specific contact. 

The Assess Risk function receives external Fleet Surveillance Data, 
Contact Identification Data from the Fix/Classify function and also Tracking Data from 
the Track function. Similar to the Fix/Classify function, many of the same systems are 
involved in assessing a contact’s risk. A contact is determined to be hostile or non- 
hostile based on information received from classification, the vessel’s known track, and 
retained history of the vessel. After analysis, the Contact Risk Assessment is mutually 
shared with other OARS systems and to the Fleet. 

The Track function also receives the Contact Risk Assessment 

information. After being invoked by a detection from the Detect function, it builds a 

database based on the Contact Risk Assessment. Paired with Contact Identification Data, 

OARS will use this information throughout its overarching Patrol function to aid in 

classification and risk assessments of all contacts. Tracking of suspicious vessels and all 

contacts will be fulfilled through use of the UAVs, ship combat systems, and the contact 

database stored within. Additionally, information in the database is intermittently 
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communicated to the fleet through use of the OARS Communicate function. The IDEFO 
representation of these interfaces, data, and functions, are shown in Figure 25. 
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Figure 25. IDEFO 2.0,‘Patrol.’ 
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d. Level 2IDEFO - 3 Communicate 

To ensure fluid and efficient operations, OARS must be capable of 
communicating externally to fleet operations and internally to its other systems. As 
mentioned previously, the Patrol function shares Contact Risk Assessment information 
and Contact Identification data with the Communicate function. While this function is 
invoked from the start of the mission, how it communicates and with whom it 
communicates are determined by the Mission Orders. 

OARS communicates externally with the Fleet, Nation States, and Civilian 
Vessels. It receives Fleet Surveillance Data from the Fleet and shares Contact Risk 
Assessment and Identification Data with them as contributions to the Common Operating 
Picture (COP). If it is in engagement with another vessel, it will share that status 
information as well. In general, OARS will share information such as CASREP reports, 
PARS prediction data, intelligence information, COP, and also request the assistance of 
an external Special Operations team if a civilian vessel has been hijacked. OARS does 
not directly engage with vessels that have already been hijacked since its primary mission 
is surveillance and deterrence. The OARS host vessel can host Special Operations forces 
if necessary. 

Internally, OARS Command & Control communicates with its UAVS, 
Pursuit Vessel, and its helicopter-based Pursuit Craft. It receives surveillance data 
through data links, which are communicated between various Patrol and Intercept 
functions. It also intercepts UHF, LHF and satellite information that typical pirates use in 
their piracy missions. Some of the capabilities involved with the internal communication 
function are sharing radar data, communicating with the UAVs, exchanging LHF/UHF, 
intercepting pirate communications and receiving distress calls. 

The Ship Communication Suite is the center of all communications, 
whether internal or external. It serves as a link between communicating externally and 
communicating internally. Almost every system in OARS has some level of 
communication, which may not be directly linked to the Ship Communication Suite. For 
example, the On-board UAS Control Station communicates directly with all UAVs. 

Information received from the UAVs is then shared with the Ship Communication suite 
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by way of the onboard UAS. Figure 26 indicates all the physical systems which 
participate in each communication domain. 
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Figure 26. IDEFO 3.0, ‘Communicate.’ 

e. Level 2 IDEFO - 4 Engage Hostile Activity 

On a typical mission, OARS continually patrols while communicating 
information it receives. If it interprets a situation to be hostile or encounters a suspected 
pirate, it will attempt to engage that hostile. Engage Hostile Activity is invoked by a 
request from the Communicate function which originally stems from Fleet Surveillance 
Data, Communication with Civilian Vessels, or Contact Risk Assessment Data obtained 
through surveillance. Engaging Hostile Activity is served primarily by the Pursuit 
Vessel, but supplemented with the UAV and Host Vessel. 

The request to engage a hostile is first received by the Intercept function. 
This complex function receives any information from the Contact Risk Assessment, 
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Civilian Vessels, and the Suspicious Vessels themselves. When the request for 
engagement is made, the Intercept function first selects the method of interception. This 
is decided between the OARS Command & Control and the Fleet Command and Control. 
Requests are then made to dispatch the Pursuit Vessel, a helicopter or a RHIB, along with 
a selected Boarding Team. If the UAV is equipped with a non-lethal deterrence system, 
such as a smoke screen or noise maker, it may participate in the deterrence function. 
After dispatching is complete, the Pursuit Vessel crew may or may not board the contact 
vessel. If so, a VBSS continues which may result in the collection of evidence and the 
arresting of pirates. Video evidence collected by the Pursuit Vessel and UAVs is also 
collected as evidence and is transferred to the Contraband/Evidence Locker and the 
database of vessel history. After deterrence is complete, pirates are given first aid, if 
required. The Pursuit Vessel also continually relays its engagement status internally to 
the OARS Command & Control, which also includes the risk level of the hostile contact. 
When the risk level of the hostile activity reaches a certain height, the Pursuit Vessel may 
relay a request to OARS Command & Control to neutralize the hostile activity. This is 
the control trigger for another function, Neutralize, as shown in Figure 27. 
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Figure 27. IDEFO 4.0, ‘Engage Hostile Activity.’ 

Neutralize is invoked by the Intercept function, when the hostile activity 
reaches an intolerable level of risk. It is satisfied by the Boarding Team and Weapon 
System operating on the Pursuit Vessel. Weapon support from the Host Vessel is 
provided, if needed. The goal of the Neutralize function is to disarm, immobilize, and 
capture the hostiles in a joint effort to minimize the potential loss of life. This includes 
deterrence of a potential hijacking. OARS holds this function as the last resort of 
elevated pursuit, before notifying special operational forces of OARS’s failure to deter. 

The request to neutralize hostile gives the Pursuit Vessel permission to 
forcefully escort the threat away from the civilian vessel. The boarding team is 
consistently fed updated information about the pirate vessel and other local threats 
throughout the Neutralize process. If escorting the threat fails, the team attempts to 
immobilize the hostile personnel. After immobilization, the pursuit team is invoked to 
disarm, capture and imprison hostiles. However, if the Pursuit team fails to immobilize, 
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the contacts’ risk assessment is asserted as imminent danger. The Boarding Team then 
proceeds to destroy the hostile contact. Remaining prisoners and evidence are collected 
and the engagement status is relayed to OARS Command & Control. The prisoners are 
given first aid before they and their associated contraband are handed over to prosecuting 
authorities. A resulting failure of the Neutralize function indicates that the civilian vessel 
has been hijacked and hostile activity now becomes a situation for the special operational 
forces, a scene external to the allocated architecture of OARS. 

/. Level 2IDEFO - 5 Mission End 

The conclusion of the OARS mission is dictated by the Mission Orders. 
Unless the OARS system becomes substantially operationally deficient, it carries out its 
functions throughout the duration of the mission. The Mission End process first checks 
out with Command. The UAS System requests retrieval of all UAVs currently in flight. 
The Host Vessel refuels through completion of an Underway Replenishment (UNREP). 
After arriving at its homeport, OARS exits the mission, indicating mission completion. 
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Figure 28. IDEFO 5.0, ‘Mission End.’ 


E. ALTERNATIVE GENERATION 

The alternatives generation phase began early during the research phase of our 
capstone project. Our team sought to answer the question: “How will we meet the needs 
of the customer?” During that phase, the design team used brainstorming techniques so 
as to not limit itself to an early solution. This section will review some of the proposed 
solutions and then use relevant information gathered to identify which of our alternatives 
were not viable and why. The alternatives that the team found to be viable are 
summarized in this section. 

The project team was tasked to design a system that will utilize existing surface 
warfare assets alongside UAV assets to counter an expanding threat to surface merchant 
trade ships and private vessels by pirate gangs. The alternatives generation portion of the 
project included exploring the ability to utilize the current government off-the-shelf 

(GOTS) systems. GOTS takes existing surveillance and detecting systems and integrates 
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them into a new OARS System. The team evaluated alternatives from a variety of 
articles and developers on the need for a pirate interdiction system to be used around the 
globe for preventing crimes on the high seas toward commercial vessels. Systems 
deployed on U.S. Navy ships in the Gulf of Aden, aircraft used during visit, board, 
search, and seizure (VBSS) activities within CTF-151, and airborne UAVs used to 
monitor activities in the Middle East region, all provided mature technology to be 
uniquely assembled for this new system design. 

The system was bounded primarily by the capabilities, configuration, and 
interfaces of the host ship. The most well suited surface ship available is the new Littoral 
Combat Ship (LCS); the surface warfare module was well matched for surface search and 
target prosecution. 

1. Materiel Alternatives Developed 

The OARS team attempted to configure different alternative solutions from 
different configurations of systems. This allowed the OARS team to then settle upon the 
best alternatives before moving onto the modeling and simulation effort. Our physical 
alternatives were developed based on our top-level systems which we considered variable 
and highly valuable to overall system effectiveness. These physical systems, chosen 
from Figure 22, were the UAS System, Flost Vessel platform, Pursuit Vessel platform, 
Weaponry, Combat Systems, and Surface Sensors. Remaining physical systems did not 
have significant variable impacts to overall OARS effectiveness, thus were not 
considered when the team determined alternatives. 

a. Alternative #1.1 

The first design alternative, “Single Platform with Stand Alone 
Operations” is intended to perform detection, tracking, and prosecution functions. It is 
called the “single system cell” since it does not rely on any other systems external to the 
OARS to perform the capability. The detection capabilities that are performed include 
nine ScanEagle UAVs, and the prosecution capability is supported with the use of two 
USMI pursuit vessels with double barreled .50 caliber machine guns mounted forward of 
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the conning structure. Due to the fact that a modified version of Spain’s DORNA 
(Direccion de tiro Optronica y Radarica NAval) fire control system has been integrated 
into the U.S. Navy’s first two LCSs, the DORNA fire control system was implemented 
into Alternative #1.1 ’s configuration. The complete list of systems included with this 
alternative is shown in Table 5. 


Table 5. Single Platform (Stand Alone Operations) List of Systems. 


Combat Systems 

Hard Kill 

The weapons 

Surface Sensors 

Net Central C4ISR 

Host Ship; MK 110- 57 
mm Gun (1) 

EADS TRS-3D C-band 
radar (air / surface 
surveillance LCS-1 

Secure Communication 

50 Cal Machine Guns 

Sea Giraffe AMB 3-D 

Crypto 

(4) 

Radar 

Common Operational 

AGM-114; Hellfire 

EO/IR Camera 

Picture 

missile (4) 

(Star SAFIRE) 

Fire Control; 

M60; 7.62 mm 

DORNA EO/IR 

DORNA 

Machine Gun 

Camera 

Sensor Processing 


ScanEagle UAV 

SH-60 Helicopter 


b. Alternative #1.2 

The second design alternative is the “Single Platform Stand Alone Version 
with an alternative UAV sensor named ExDrone.” This alternative is intended to use the 
OARS for detection, tracking and prosecution functions; however, it will use an 
alternative UAV. The combat systems category remains the same as with the first 
alternative. In the surface sensors category, our team has attempted to match the 
capability of the on-board UAV SAR radar and EO/IR camera. The complete list of 
systems included with this alternative is shown is Table 6. Even though this alternative 
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utilizes a different UAV, the total number of persons required to operate it remains the 
same (two per shift). 


Table 6. Single Platform (Stand Alone Operations) List of Systems. 


Combat Systems 

Hard Kill 

The weapons 

Surface Sensors 

Net Central C4ISR 

Host Ship; MK 110- 57 
mm Gun (1) 

EADS TRS-3D C-band 
radar (air / surface 
surveillance LCS-1 

Secure Communication 

50 Cal Machine Guns 

Sea Giraffe AMB 3-D 

Crypto 

(4) 

Radar 

Common Operational 

AGM-114; Hellfire 

EO/IR Camera 

Picture 

missile laser guided (4) 

(Star SAFIRE) 

Fire Control; 

M60; 7.62 mm 

DORNA EO/IR 

DORNA 

Machine Gun 

Camera 

Sensor Processing 


ExDrone UAV 

SH-60 Helicopter 


c. Alternative #1.3 

The third design alternative is the Single Platform with a change to the 
surface and airborne pursuit vessels. The surface vessel is being changed to a Zodiac 
rigid hulled inflatable boat, and the airborne pursuit vessel is being changed to a MQ-RB 
Fire Scout unmanned helicopter. 

The Fire Scout has started to make a name for itself in recent Naval 
missions. Just recently, during the 2011 Lybian Civil War, a MQ-RB Fire Scout was 
used in targeting missions under NATO command. The Fire Scout is denoted as a 
Vertical Takeoff Unmanned Aerial Vehicle (VTUAV). 

The cost of operating a VTUAV in place of a manned SH-60 helicopter is 
significantly less. The U.S. Navy expects to acquire delivery of three new Fire Scouts 
this year and twelve more aircraft in 2012. According to one report, Congress has been 
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asked to boost the funding for this VTUAV by $46 Million in 2012 to raise the inventory 
to a total of 56 aircraft by the end of 2012 (Ackerman 2011). The difference in this 
alternative would be most notably the use of a weapons platform UAY. The manning 
requirements of this solution are very low, at three officers and three enlisted technicians 
per UAV system compared with 19 total staff to support an air detachment for an SH-60 
Sea Hawk (Raymer 2009, 31) (Stracker 2007, pg. v). The complete list of systems 
included with this alternative is shown is Table 7. Even though this is an unmanned 
UAV pursuit aircraft, it was determined that there would be a requirement for two UAV 
operators aboard the host ship. 

Table 7. Single Platform (Stand Alone Operations) List of Systems. 


Combat Systems 

Hard Kill 

The weapons 

Surface Sensors 

Net Central C4ISR 

Host Ship; MK 110- 57 
mm Gun (1) 

EADS TRS-3D C-band 
radar (air / surface 
surveillance LCS-1 

Secure Communication 

50 Cal Machine Guns 

Sea Giraffe AMB 3-D 

Crypto 

(4) 

Radar 

Common Operational 

AGM-114; Hellfire 

EO/IR Camera 

Picture 

missile laser guided (4) 

(Star SAFIRE) 

Fire Control; 
DORNA 

Two pods of four 
70mm folding wing 
Hydra rockets 

DORNA EO/IR 
Camera 


Advanced Precision 


Sensor Processing 

Kill weapons laser 

ExDrone UAV 


guided 


Fire Scout VTUAV 

Viper Strike precision 
munitions 



d. Alternative #1.4 

The fourth design alternative is hosted by the Littoral Combat Ship (LCS). 
With this alternative, the team would not alter the OARS significantly outside the UAV 
sensor. This alternative is shown in Table 8. 
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Table 8. Single Platform (Stand Alone Operations) List of Systems. 


Combat Systems 

Hard Kill 

The weapons 

Surface Sensors 

Net Central C4ISR 

Host Ship; MK 110- 57 
mm Gun (1) 

EADS TRS-3D C-band 
radar (air / surface 
surveillance LCS-1 

Secure Communication 

50 Cal Machine Guns 

Sea Giraffe AMB 3-D 

Crypto 

(4) 

Radar 

Common Operational 

AGM-114; Hellfire 

EO/IR Camera 

Picture 

missile laser guided (4) 

(Star SAFIRE) 

Fire Control; 
DORNA 

Two pods of four 
70mm folding wing 
Hydra rockets 

DORNA EO/IR 
Camera 


Advanced Precision 


Sensor Processing 

Kill weapons laser 

ExDrone UAV 


guided 


Fire Scout VTUAV 

Viper Strike precision 
munitions 



e. Alternative #1.5 

The fifth design alternative found additional options in the host ship. The 
exceptional Command, Control, and Communications capability with the LPD would be 
available as a single cell vessel in company with additional destroyers and frigates 
combined specifically in a set of six to cover the Gulf of Aden transit corridors. The 
extensive aircraft facilities onboard the LPD offers the six system cells ample support but 
which also require maintenance and repair facilities afloat. With this alternative, the 
team would build a duplicate system around the host ship as in alternative 1.1. This 
Alternative is shown in Table 9. 

Table 9. Single Platform (Stand Alone Operations) List of Systems. 


Combat Systems 

Hard Kill 

The weapons 

Surface Sensors 

Net Central C4ISR 

Host Ship; MK 46 Mod 

Thermal imager 

1-30 mm Gun (2) 

director Camera 
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Secure Communication 
Crypto 

MK26 Mod 18 50 Cal 
Machine Guns (2) 

Northrop Grumman 
Norden Systems 
AN/SPS-73 surface 
search radar operating at 
I-band (2) 

Common Operational 
Picture 

AGM-114; Hellfire 
missile laser guided (4) 

Lockheed Martin 
AN/APQ-9B surface 
surveillance and tracking 
radar operating at I band 

Sensor Processing 

M60; 7.62 mm 
Machine Gun 

ScanEagle UAV 

SH-60 Helicopter 

MK 2 SSDS will be an 
integration of all the 
ship's self-defense 
systems and will include 
multi-function radar, 
advanced integrated 
electronic warfare 
system and infrared 
search and track system 
(IRST). 


/. Alternative #1.6 

The sixth design alternative is the LPD host ship upgrade with the Fire 
Scout VTUAV. With this alternative, the team would build a system around an 
alternative RHIB named Zodiac. The advantages to the Zodiac RHIB over the USMI is 
in a larger personnel capacity and its increased speed, which is slightly more at 48 knots 
(versus 46 knots). Additionally, the cost is a quarter of that of the USMI vessel. This 
alternative is shown in Table 10. 


Table 10. Single Platform (Stand Alone Operations) List of Systems. 


Combat Systems 

Hard Kill 

The weapons 

Surface Sensors 

Net Central C4ISR 

Host Ship; MK 46 Mod 
1-30 mm Gun (2) 

Thermal imager 
director Camera 

Secure Communication 
Crypto 

MK26 Mod 18 50 Cal 
Machine Guns (2) 

Northrop Grumman 
Norden Systems 
AN/SPS-73 surface 
search radar operating at 
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I-band (2) 

Common Operational 
Picture 

AGM-114; Hellfire 
missile laser guided (4) 

Lockheed Martin 
AN/APQ-9B surface 
surveillance and tracking 
radar operating at I band 

Sensor Processing 

M60; 7.62 mm 
Machine Gun 

ScanEagle UAV 

Fire Scout VTUAV 

Two pods of four 
70mm folding wing 
Hydra rockets 


MK 2 SSDS will be an 
integration of all the 
ship's self-defense 
systems and will include 
multi-function radar, 
advanced integrated 
electronic warfare 
system and infrared 
search and track system 
(IRST). 

Advanced Precision 
Kill weapons laser 
guided 


Viper Strike precision 
munitions 


g. Alternative #1.7 

The seventh design alternative is the fifth alternative with the alternative 
UAV sensor, ExDrone. With this alternative, the team would be able to measure the 
effectiveness of the alternate UAV with the more advanced LPD support package, 
considering that the deployment of large numbers of UAVs and Fire Scout armed 
VTUAVs has not occurred to date. The maintenance requirements necessary to sustain 
this configuration will be valuable modeling and simulation data. This alternative is 
shown in Table 6. 


Table 11. Single Platform (Stand Alone Operations) List of Systems. 


Combat Systems 

Hard Kill 

The weapons 

Surface Sensors 

Net Central C4ISR 

Host Ship; MK 46 Mod 

Thermal imager 

1-30 mm Gun (2) 

director Camera 
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Secure Communication 
Crypto 

MK26 Mod 18 50 Cal 
Machine Guns (2) 

Northrop Grumman 
Norden Systems 
AN/SPS-73 surface 
search radar operating at 
I-band (2) 

Common Operational 
Picture 

AGM-114; Hellfire 
missile laser guided (4) 

Lockheed Martin 
AN/APQ-9B surface 
surveillance and tracking 
radar operating at I band 

Sensor Processing 

M60; 7.62 mm 
Machine Gun 

ExDrone UAV 

SH-60 Helicopter 

MK 2 SSDS will be an 
integration of all the 
ship's self-defense 
systems and will include 
multi-function radar, 
advanced integrated 
electronic warfare 
system and infrared 
search and track system 
(IRST). 


2. OARS’s Zwicky’s Morphology 

The seven alternatives were evaluated using a combination of procurement costs 
and mission requirements. A procurement cost analysis was conducted to determine the 
host vessel with the least cost to be utilized by the OARS system. Since the CONOPS 
described the use of six individual OARS systems working together to provide coverage 
throughout the entire Gulf of Aden, a total of six different host vessels was required. 
This cost analysis can be found in Appendix E. A combination of six Littoral Combat 
Ships (LCS) was the cheapest of the host ship combinations. The LPD and DDG 
platforms are considerably more costly to build than the newer LCS ships, at over a 
billion dollars each. Another issue arises with the fact that FFG class ships will not be 
procured in the future. The OARS team also noted that integrating several UAVs with 
two ground control stations across three different ship classes would be difficult. Due to 
these issues, alternatives 1.5, 1.6 and 1.7 were eliminated immediately. 
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The OARS team then evaluated how each of the other alternatives measured up to 
the mission requirements. This process was facilitated using a simple Zwicky’s 
morphological box, which is located below in Table 12. Mission requirements were 
placed into five categories: 

1. Combat systems 

2. Sensors 

3. Capture and Detention 

4. Weapons 

5. UAV Endurance 


Table 12. Zwicky’s Morphological Box. 


Combat 

Systems 


LCS 


COP 


SA 


Net Centric 


GCS 


High Altitude 
UAV 

★ t 


Sensors 


IR 


EO 


Video 


Capture and 
Detention 


Armed, 
Manned Helo 



Armed, 
Manned- 
Pursuit Boats 


Helo 


UAV 

Endurance 


< 5 hrs 


5-15 hrs 


Brig Facility Pursuit Boats > 15 hrs 


★ 

= Alternative 1.1 


= Alternative 1.2 


= Alternative 1.3 

• 

= Alternative 1.4 
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The remaining alternatives adequately supported combat systems, sensors, and 
weapons requirements. Alternatives 1.1 and 1.2 satisfy the “capture and detention” 
requirement the best by including a SH-60 helicopter. Alternatives 1.3 and 1.4 utilize the 
MQ-B8 Fire Scout VTUAY instead of the SH-60 helicopter. The VTUAV is a very 
capable system and has a lower life cycle cost than the SH-60, however, due to its limited 
“capture and detention” capabilities, it was not considered as a preferred option for the 
OARS system. The SH-60 will also prove more valuable in keeping detected pirates at 
bay until the pursuit vessels arrive. For this reason, Alternatives 1.3 and 1.4 were not 
considered as optimal for the OARS system. 

The next subsystem evaluation criteria examined by the OARS team was the 
endurance of the UAVs. Although the ExDrone UAV option was found to be less costly, 
it suffers when it comes to endurance. Its mission is limited to less than 5 hours, while 
the ScanEagle has an endurance of over 18 hours. Much more time will be spent 
searching for pirates over a much greater area if the ScanEagle UAV is used instead of 
the ExDrone. Both Alternatives 1.1 and 1.3 utilize the ScanEagle UAV and therefore 
they both perform the best when it comes to UAV endurance. Due to the fact that 
Alternative 1.1 provides both a strong “capture and detention” capability and provides a 
very large UAV endurance range, it was selected as the most preferred alternative. 
Alternative 1.1 can be adjusted to add up to 12 ScanEagles per OARS system. The 
simulation will also evaluate an augmented configuration incorporating a long range 
airship such as BAMS. 

3. Recommended Alternatives 

a. Alternative 1, Basic OARS 

Due to the results of the Zwicky’s Morphology Box, Alternative 1.1 will 
be carried into the analysis phase of the systems engineering process and will be 
considered as “Basic OARS.” The subsystems that will make up Alternative 1 are 
detailed in Table 5. 
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b. Alternative 2, Augmented OARS 

The other alternative that was selected to be modeled had the same 


configuration as Alternative 1.1, but also was augmented by Wide Area Surveillance 
airships or BAMS. This allowed the OARS team to analyze the benefits of adding a 
land-launched airship to the Basic OARS system to allow for greater surveillance of 
pirate activity. The analysis of both alternatives is further discussed in the next Chapter. 
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IV. MODELING AND ANALYSIS 


A. TOOLS AND APPROACH 

The Naval Simulation System (NSS) software package, which was used for 
modeling and simulation (M&S) of the OARS system, was developed by the Space and 
Naval Warfare Center SPAWAR (PD-15) (Information Support Systems) and Metron 
Inc. from Reston, YA. This software uses object-oriented Monte Carlo Modeling to 
simulate complicated interactions between individual objects. NSS is centered around 
the support of operational commanders in developing and analyzing operational events 
that are driven by either decisions made, or the selected courses of action at a mission 
group or force level. 

The OARS Team used the scenario based modeling within NSS for the purpose of 
establishing base-line functional models, applying variances to the models to test each 
alternative effectively, and capturing the necessary data from alternatives in order to 
compare quantitative output values. This provided the team with a set of feasible 
alternative system arrangements that were tested against the identical constraints. This 
helped to frame the best solution to this system. 

The basis of selecting NSS was primarily because of its capability for modeling 
two opposing forces in a dynamic environment with a geographic world overlay for 
reference. Each study was primarily focused on reducing the number of successful pirate 
attacks based on known effective deterrents. Specific resources can then be allocated to 
experimental combinations of surface ships, helicopters, and UAVs, with the overall goal 
of deterring piracy. Allocating specific resources primarily refers to having compatible 
combinations of surface combatants loaded with accompanying helicopter crews and a 
UAV detachment, working together to combat the threat of piracy. The allocation of 
experimental resources refers to combining relatively untested combinations of resources. 
Examples of these untested resources were a blimp-like airship and an array of UAVs 
that were deployed to assist in combating the threat of piracy. The individual scenarios 
setups in NSSs will be laid out in more detail in the “Model Scenario” section of this 
chapter. 
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The basic methodology when conducting OARS system modeling and simulation 
(M&S) was to provide a multi-preference objective model that allowed the Measures of 
Effectiveness (MOEs) to be weighed in accordance with the systems engineering process. 
The MOEs were measures drawn from the original stakeholder requirements and mapped 
to the available outputs from the NSS program scenarios. Table 13 below lists the MOEs 
that were used to establish the modeling criteria. The MOEs were taken from default 
MOE templates available within the NSS program. 


Table 13. Measures of Effectiveness (MOEs). 


Name 

Rank 

Template (NSS) 

Red Assets Destroyed (Pirates Overtaken) 

1 

Asset Destroyed 

Blue Assets Destroyed (Cargo Ships Overtaken) 

2 

Asset Destroyed 

Red Weapon Launches (Pirate Overtake 

Attempts) 

3 

Weapon 

Launched 

Blue Weapon Launches (OARS Overtake 
Attempts) 

4 

Weapon 

Launched 

Blue Surveillance Classifications (OARS) 

5 

Surveillance 

Classifications 

UAV Cumulative Launches (OARS) 

6 

Aircraft 

Cumulative 

Launches 

Blue Surveillance Detections (OARS) 

7 

Surveillance 

Detections 


Throughout the following explanations of the modeling setup, red and blue assets 
will refer to the two opposing forces that were set up in NSS to model the behavior of the 
OARS system and its components. NSS and the two opposing forces are discussed in 
further detail below. The MOEs were an integral portion of the model design and were 
necessary in comparing the various system alternatives. The MOEs were gathered as 
outputs from the model. Results from the model are outlined in further detail in the 
“Results” section of this chapter. 

Modeling efforts were focused on accurately simulating pirate and cargo ship 
activity in the Gulf of Aden to cover approximately 390,000 square miles of effective 
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piracy interdiction. The simulation efforts continually grew from the modeling successes 
where initial run data was able to pass basic validity tests of plausible and non-plausible 
data. The initial analysis of such data helped to produce a confidence in the data that was 
being produced while modeling the current CTF-151 system and the alternative OARS 
scenarios. These efforts were accomplished by using NSS’ study management and 
export tools to output multiple replications of scenarios to Microsoft Excel for analysis. 
The more robust tools within the NSS proved to be more difficult to master as students, 
but perseverance and assistance from the OARS’s capstone advisor allowed the group to 
successfully model four separate alternative scenarios. 

While modeling OARS, two opposing forces (red and blue) were created. The 
blue forces consisted of U.S. Navy surface ships, UAVs, and merchant vessels. These 
blue forces were pitted against the red forces, which consisted of red pirate surface craft 
who were attempting to hijack and ransom merchant vessels. Scenarios were developed 
by introducing specific ship paths, tactics, defensive actions, and hostile actions. 
Background information, such as the origin of pirate attacks and known merchant 
shipping lanes, were learned during the OARS team’s initial piracy research. Figure 29 
below shows a NSS screenshot displaying the cargo tracks used as a baseline to simulate 
the busiest corridor through the Gulf of Aden. 



Figure 29. NSS Cargo Track Display. 


83 













Table 14 outlines the matrix used to develop objects in modeling scenarios. 
Scenario development consisted of setting up two separate alliances. Each of the 
alliances were assigned resources, some of which are shown below. Commanders were 
assigned to each of the alliances in order to assign alliance tactics, object properties, and 
movement actions. Individual entity tactics and properties are discussed in further detail 
in the ‘Modeling Tactics’ section of this chapter. 

B. MODEL SCENARIOS 

Table 14 outlines the number of ships used for each of the four modeling 
scenarios. The four modeled scenarios are described in more detail in the following 
sections. All scenarios had a time frame of a 30 day window to simulate the number of 
interactions in a single month. The 30 day window was also chosen to decrease NSS 
server processing time when running multiple replications through the study management 
mode. 


1. Pirates Unopposed (Baseline) 

This scenario was the baseline model where the pirates were unopposed and 
openly attacked merchant vessels without resistance. Container ships were assigned 
repeating tracks travelling through the corridor of the Gulf of Aden through which ships 
transit. Originally, 500 cargo ships were to be modeled going back and forth through the 
gulf, but due to NSS memory limitations, the OARS team was forced to scale this 
number down to 355. The container ships were assigned an in-and-out track that they 
would travel, which was straight down the middle of the Gulf of Aden. One hundred 
pirate motherships and 200 pirate skiffs (two per mothership), were equally divided 
among five separate but equally sized regions within the 390,000 square miles in the Gulf 
of Aden. Within each region, 20 red pirate motherships were assigned a patrol movement 
in which the motherships would actively search for blue container ships to attack. 
Motherships were given a “visual radar” property to allow them to scan for container 
ships up to nine miles away, which is reasonable given the size of the ships and the 
assumption that binoculars may be used. Upon confirmation of container ship sighting 
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within a nine mile radius, the mothership would launch attack pirate skiffs. When the 
pirate skiffs arrived at the container ships, the attack would begin and a successful 
overtake of the container ship being successfully undertaken would be reported when the 
blue ship was eliminated. This baseline allowed additional follow-on scenarios to be 
built upon its structure: additionally, it provided a “worst case scenario” number of 
successful pirate attacks without any opposition from U.S. or allied naval forces. The 
MOE data was gathered after running the scenario for three replications and then the data 
was exported to an Excel spreadsheet for analysis. 


Table 14. Scenario Objectives and Quantities. 


Object Name 

Baseline 1 

- No 

Naval 

Support 

Baseline 2- CTF 

151 (Scaled to .39 

Million sq. miles) 

OARS 

Alternative 1 

-LCS Host 

Ships 

OARS 

Alternative 2 - 

LCS Host Ships 

w/Air Support 

AK Amur Cargo Ships 

355 

355 

355 

355 

Pirate Motherships 

100 

100 

100 

100 

Pirate Skiffs 

200 

200 

200 

200 

SH-60 Helos 

0 

2 

0 

0 

USN LCS Class Ships 

0 

0 

6 

6 

USN DDG Arliegh Burke Class Ships 

0 

2 

0 

0 

USN FFG Perry Class Ships 

0 

1 

0 

0 

USNLPD San Antonio Class Ships 

0 

1 

0 

0 

Chinese Jianwei Frigates 

0 

2 

0 

0 

Korean USL AN Frigates 

0 

1 

0 

0 

Turkey Barbaros Frigates 

0 

3 

0 

0 

Singapore Formidable Frigates 

0 

2 

0 

0 

Canadian Halifax Frigates 

0 

1 

0 

0 

French Floreal Frigates 

0 

1 

0 

0 

Dynalifter Hybrid Airships 

0 

0 

0 

1 

Scan Eagle UAVs 

0 

2 

54 

54 
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2. CTF-151 (Currently Existing Scenario) 

This scenario was modeled to simulate the current efforts of the CTF-151 
coalition force. CTF-151, as previously explained, consists of U.S. Navy and allied ships 
working together to combat piracy in the Gulf of Aden. The blue Navy alliance ships 
that were modeled included a DDG 51 Arleigh-Burke Class destroyer, LPD 17 San 
Antonio Class Amphibious assault ship, and a FFG Oliver Hazard Perry Class Frigate. 
Also included in the “Blue” alliance were ten coalition vessels which make up the 
majority of CTF-151. Coalition vessels included Chinese Frigates (Jianwei Class), 
Korean Frigates (ULSAN Class), Turkey Frigate (Barbaros Class), Singapore Frigate 
(Formidable Class), Canadian Frigate (Halifax Class), and French Frigate (Floreal Class) 
platforms. Though the Chinese Frigates are not strictly part of CTF-151, they are 
deployed there to protect the commercial interests of the Chinese government and assist 
with the overall effort to deter piracy. Certain coalition vessels were modeled with SH- 
60 SeaHawk Helicopter capabilities; these were the Singapore ships and Turkish ships. 
Coalition vessels that were modeled with UAVs were the Canadian Frigates (SH3D Sea 
King) and the French Frigate (Z9C Dauphin). Refer to Table 14 above for the exact 
number of each of the coalition and Navy ships modeled in this scenario. All ships had 
inherent weapon properties that were adjusted in order to reflect international law that 
suspected pirates are not to be treated as enemy combatants. Thus all missile launch 
capabilities and anti-aircraft guns were removed, allowing only small caliber deck 
machine guns to be utilized. Each ship was assigned a patrol track in each of the six 
equally sized pirate zones which allowed them to deter and intercept pirates only in their 
region. All sensor properties were left at the default NSS inherited value. This allowed 
the ships to detect the presence of motherships and thus, the pirate skiffs. The 100 pirate 
motherships with accompanying 200 pirate skiffs were carried over from the baseline 
scenario and modeled identically. SH-60 Helicopters and a limited number of UAVs 
were added to this scenario to reflect the current limited use of UAVs utilized in CTF- 
151 presently. UAVs were treated as aircraft objects in the model and therefore the 
inherent properties of the UAVs were left at default inherited NSS values. Pirate kills 
were recorded as pirate ships that were overtaken and confirmed through a MOE output 
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of Red Asset Destroyed. Data was gathered for three scenario replications and 
automatically exported to a spreadsheet for analysis. 

3. LCS Host Vessel with UAVs (OARS Basic) 

This scenario was modeled using multiple UAVs to increase the sensor range of 
the surface ship as well as increase the sensor effectiveness of the blue alliance. This 
scenario introduced six Littoral Combat Ship (LCS) host vessels and 36 ScanEagle UAVs 
(6 per LCS) for piracy detection sensors. For an exact breakdown of the number of 
platforms modeled, please refer to Table 14. All host ship platforms used in NSS had the 
built in capability to launch and recover multiple UAVs. In this scenario, all of the U.S. 
Navy ships and coalition vessels were again divided equally among the six piracy zones. 
All 200 pirate skiffs and 100 motherships left at their previously assigned zones with the 
red alliance. All blue Navy assets were assigned the same patrol sweeps to look for 
pirates as in the CTF-151 scenario described above. The UAV that was assigned to 
launch from all U.S. Navy ships was the ScanEagle with a patrol track within one of the 
five designated piracy areas. Upon confirmation of a pirate vessel sighting, the UAV 
would report back to the host vessel and the host vessel would utilize its superior speed 
and range to attempt to overtake and eliminate the pirate threat. This overtake action was 
not explicitly shown in the model due to the fact that the action of overtaking a pirate 
vessel was measured through the Red Asset Destroyed MOE. Though the speed 
properties assigned to pirate skiffs were greater than all of the U.S. Navy and coalition 
ships, the craft’s range was limited. For an exact breakdown of derived, assumed, and 
calculated values for pirate skiffs and motherships, please refer to Appendix C. Once the 
pirate skiffs returned to the pirate mothership, the speed of the mothership was limited to 
that of a typical fishing vessel, allowing any one of the blue alliance to overtake and 
eliminate the threat. Data was gathered from three replications of the scenario and 
automatically exported to a spreadsheet for analysis. 

4. LCS with Air Support Vessel (OARS Augmented) 

During the modeling and scenario development for the LCS with Air Support 

concept, the NSS program database was erased through a Naval Postgraduate School 
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(NPS) technician’s error. This ultimately wiped out all existing OARS scenarios. This 
loss of data erased all earlier model development and did not allow the team to complete 
the scenario listed below. Therefore, this scenario is described purely as an area for 
further research and future investigation, as there was no output data available. 

This scenario was to be modeled identically to the LCS host ship scenario 
(OARS Basic), with the added support of a hybrid airship to increase the detection range 
and effectiveness of the blue alliance. The unmanned airship was to be land-based but 
capable of greater endurance and range to exponentially increase the sensor effectiveness 
of the alliance. As seen from Table 14, the six LCS class were all to be modeled with 
associated ScanEagle UAVs. The airship selected for this scenario was the MDL-100X1 
Dynalifter. This aircraft was not available in the default database of objects in NSS so an 
equivalent aircraft was chosen to simulate it as closely as possible. The baseline aircraft 
for modification to the airship was an E2 Hawkeye. Speed, range, detection capability, 
and fuel capacity properties were all altered to reflect the MDL-100X1 Dynalifter as 
closely as possible. The actual detection capability of the MDL-100X1 Dynalifter is 
extensive, but still not quite as effective as the actual E2 Hawkeye so the sensor 
capability property was adjusted. As in previous scenarios the blue alliance ships were 
divided between the five zones along with their accompanying UAV squadrons. One 
“MDL-100X1 Dynalifter” was assigned to this scenario and its path was a racetrack path 
around the entire Gulf of Aden operating area. This scenario was fully modeled, but 
because of the deletion of the NSS database, no outputs could be measured. 

C. MODELING PARAMETERS 

Modeling tactics were based on assignable tactics table actions available within 
NSS. The tactics essentially dictated how the model object would react when presented 
with an opposing asset object. NSS allowed multiple behaviors to be simulated 
concurrently in order to best represent real-world actions of surface ships, UAVs, and 
helicopters. By manipulating the behaviors and operating rules for each asset, different 
scenarios could be customized to suit the needs of each individual alternative. For a 
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complete list of the individual object tactics and their associated responses, please refer to 
Table 15. 


Table 15. Modeling Tactics by Platform. 


Platform 

Tactic 

Tactic Description 

Pirate Skiffs 

Attack/Avoid Air Tactic 

Attacks blue cargo vessels but avoids UAVS or 
Naval vessels when detected 

Cargo ships 

Report All Tactic 

Reports pirate attacks back to the "cargo base" 
to spread the word to other cargo ships 

Naval Vessels 

Anti-Piracy Tactic 

Attacks red vessels in range of weapons and 
also includes a reporting aspect to share piracy 
detection information with the coalition forces 

Pirate Motherships 

Avoid Air Tactic 

Avoids UAVS or Naval vessels when detected 

UAVs 

Report All Tactic 

Reports aerial information back to the naval 
commander about asset detections and 
classifications (blue or red asset) to spread 
information to the other coalition forces 

Airship 

Report All Tactic 

Reports aerial information back to the naval 
commander about asset detections and 
classifications (blue or red asset) to spread 
information to the other coalition forces 


Interaction tables were also used to set up the effectiveness of weapons against 
different classes of ships. For example, small deck weapons on the blue assets were 
given a probability of hit (Ph) of around 0.8 for the larger pirate motherships, and a lower 
Ph of around 0.4 for the smaller pirate skiffs. Additionally, the pirate skiffs were set to 
be un-attackable with larger weapons, such as harpoons, which would essentially be 
ineffective in a real world scenario. All the missile capabilities and large scale weapons 
of the blue alliance were considered unrealistic in the model and also not allowed by 
international law for use against suspected pirates. Due to this reason, the Ph of all large 
weapon and missile capabilities were set to zero. 

Mission plans were another aspect of the NSS modeling that applied to UAV 

launches and pirate skiff launches. In order for the surface ships (either alliance) to 

launch a secondary craft, mission plans needed to be defined in order to specify the 

timing and launch conditions. UAVs were launched off of all surface craft in regular 

intervals, with a rotating pool of assets to keep a 24 hour surveillance window. LCS 
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ships had a larger pool of 9 UAV assets (versus other naval surface ships) in order to 
improve availability within the operating zone. Pirate skiffs were launched from the 
mothership upon detection of a cargo ship to initiate an attack, and recalled to the 
mothership upon detection of an opposing blue force UAV or surface ship. 

Model objects were also assigned specified motion parameters in order to initiate 
realistic interactions in the scenarios. The motion of each asset is described in Table 16 
below. 


Table 16. Asset Motion. 


Asset Type 

Motion Type 

Motion Description 

Blue Cargo Ship 

Track 

355 cargo ships were assigned 

fixed motion tracks across the 

Gulf of Aden and travelled a 

repeating path back and forth. 

Red Pirate Motherships 

Area Patrol 

Five separate pirate operating 

areas were established 

throughout the Gulf of Aden and 
20 pirate motherships were 
confined to patrol each area 

using the default NSS "patrol" 

function. 

Blue Navy & Coalition Ships 

Area Patrol 

Five separate pirate operating 

areas were established 

throughout the Gulf of Aden and 

all available blue assets were 

spread across the operating 
areas in order to patrol for red 
assets using the default NSS 
"patrol" function. 

Blue UAVs and helicopters 

Area Patrol/Detect 

Mission plans were used to 

launch all aerial vehicles and the 

vehicles used the default NSS 

aerial "patrol" function to detect 
and classify all assets. 

Red Pirate Skiffs (modeled as 

aerial vehicles due to NSS 

constraints) 

Area Patrol 

Mission plans were used to 
launch the pirate skiffs and the 

skiffs used the default aerial 

"patrol" function to attack blue 
cargo assets. 
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D. RESULTS 

Because of the inadvertent loss of the NSS database during scenario development, 
only limited data for three out of the four scenarios is available in this section. The 
results shown below in Table 17, MOE Outputs, indicate that there were no large 
discernible differences between the effectiveness of the Basic OARS system and the 
current CTF-151 solution. The major difference that the model did indicate was that 
there were 130,379 UAV detections compared to CTF-151's 91,179. This is due to the 
fact that the OARS system had 875 launches, and CTF-151 only had 277. 

CTF-151 had more pirate arrests (overtakes) than the OARS system, but the 
OARS system used its UAV presence to deter pirates from attacking. An “aircraft avoid 
tactic” was built into all red assets in the NSS models. This meant that the modeled 
pirates would be less likely to commit acts of piracy if they spotted the surveillance 
UAVs overhead. Due to this aspect of the model, the fact that the OARS system lowered 
the amount of piracy attempts was an expected outcome. Additionally, the OARS system 
was slightly more effective in combating pirate motherships in terms of the overtake 
percentage MOE, but again, the system utilizes newer, more effective LCS ships with 
better weapons, and depends more on UAV presence to deter piracy. 

One of the major MOEs for this system is “percentage detection measurement.” 
OARS performed well in this area with an overall average number of detections at 
130,379 versus 91,171 in the CTF-151 scenario. This indicates that further research into 
the area of aerial long range sensors (such as those on the hybrid airship in the OARS 
Augmented scenario) should be conducted in the future to enhance anti-piracy efforts. 
The presence of a UAV in hostile ocean areas appears to be a simple deterrence method 
to combat piracy. Empirical, quantitative, research methods need to be employed in the 
field to further test and validate the effectiveness of this deterrence method. 
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Table 17. MOE Outputs by Scenario and MOE. 


Unopposed Baseline (3 replications) 

MOE name 

Average 

Red Assets Destroyed (Overtaken) 

0 

Blue Assets Destroyed (Overtaken) 

57.7 

Red Weapon Launches (Overtake Attempts) 

123 

Blue Weapon Launches (Overtake Attempts) 

0 

CTF 151 (3 replications) 

MOE name 

Average 

Red Assets Destroyed (Overtaken) 

9.3 

Blue Assets Destroyed (Overtaken) 

30.0 

Red Weapon Launches (Overtake Attempts) 

87.3 

Blue Weapon Launches (Overtake Attempts) 

27.7 

Blue Surveillance Classifications 

9937 

UAV Cumulative Launches 

277.3 

Blue Surveillance Detections 

91179.7 

Red Successful Overtake % (Derived MOE) 

34.3% 

Blue Successful Overtake % (Derived MOE) 

32.5% 

OARS BASIC (3 replications) 

MOE name 

Average 

Red Assets Destroyed (Overtaken) 

3 

Blue Assets Destroyed (Overtaken) 

27.3 

Red Weapon Launches (Overtake Attempts) 

82.0 

Blue Weapon Launches (Overtake Attempts) 

6.7 

Blue Surveillance Classifications 

49223 

UAV Cumulative Launches 

875 

Blue Surveillance Detections 

130379.3 

Red Successful Overtake % (Derived MOE) 

32.4% 

Blue Successful Overtake % (Derived MOE) 

45.0% 


E. MODEL LIMITATIONS 

Some limitations associated with the NSS software constrained the team’s ability 

to simulate the OARS concept in a realistic manner. One limitation associated with the 

NSS software was that entering new MOEs into the system instead of utilizing the ones 

that were already built into the program was a very complex process. This drove the 

team to select measurements under default classes available within NSS such as asset 

destruction, weapon launches, UAV launches, sensor classifications, and sensor 

detections. These measurements fit well with the stated systems engineering process, so 
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restrictions on MOE data was not a big issue. Future studies in the area of anti-piracy 
systems may elect to customize NSS MOE outputs to better tailor them to the project 
requirements. 

The NSS software is based on traditional naval warfare interactions between 
known enemies, and therefore is not always flexible in adapting to a non-traditional and 
evasive enemy like pirates. Since the pirates often use evasive tactics such as disguising 
the motherships as fishing boats, the blue asset detection characteristics were difficult to 
model realistically. Often in the scenario, a blue force asset would be immediately aware 
that a red enemy force is nearby through the use of detection sensors, while in real life, 
the pirate assets are difficult to identify because they mix in so well with normal 
merchant traffic. This issue was somewhat mitigated by using a timed hostile action flag. 
Blue vessels were not allowed to engage pirate vessels unless a hostile action had taken 
place within a set amount of time. This feature simulated the ability of the pirates to 
blend back into the background traffic if they were not engaged quickly. 

Cargo/container ships were difficult to model within the scenarios because of the 
sheer number of transport ships that operate in the Gulf of Aden. Exact paths for ships 
were difficult to model because of the variability within shipping origin ports and 
destinations. Therefore, the modeling team chose to simulate 1000 ship crossings over 
the course of a month by utilizing 500 blue cargo vessels on a continuous back and forth 
loop in areas known to have the most piracy. The actual number of blue cargo vessels 
was finalized at 355 assets because of NSS memory constraints, but the team has 
reasonable assurance that at least 1000 crossings were made over the course of 30 days in 
all four scenarios (since each scenario had at least 3 crossings through the Gulf of Aden 
by each cargo ship). 

Other limitations included a limited number of baseline platforms in the NSS 
database, especially when it came to new classes of surface ships and UAVs. This meant 
that many existing platforms had to be extensively modified in order to fit the operating 
parameters of the new platforms like the LCS, Dynalifter Hybrid Airship, and ScanEagle 
UAV. Major modifications to the ship object properties were often time consuming and 

many times led to NSS software run errors when scenarios would be replicated. 
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Refinement of the new object properties was a continual process in order to ensure that 
the NS S simulations ran smoothly. 

Furthermore, some surface assets, such as pirate skiffs, needed to be modeled as 
aerial assets due to NSS constraints of only being unable to launch surface craft from 
surface ships. This had little effect on the interactions within the model, since the pirate 
skiffs were simply modeled as UAVs with an elevation of zero and the ability to attack 
cargo ships. 

In conclusion, although there were limitations to the NSS software, the OARS 
team was able to produce three separate scenarios which were effective in depicting the 
important parameters and measuring the MOEs related to real-world piracy interactions. 
The NSS software package was only partially capable of modeling the real world piracy 
interactions, and it was instead designed more for traditional warfare between two known 
enemies. Due to this, a more flexible software package may be required in the future, if 
research is continued in the area of anti-piracy. 

F. COST ANALYSIS 

Each OARS alternative is comprised of subsystems that need to be initially 
procured from existing programs. Costs were derived from published documents found 
from the respective program research. Initial costs include the current market costs of 
each alternative system with the correct inflation indices applied. Procurement of future 
alternatives to replace that item is done through the acquisition strategy using an 
incremental, technical refresh process. The initial procurement costs account for the 
majority of funding for each system. 

Future year spending provides a method of determining where and when funding 
should be applied. Inflation rates have been used to establish out year costs, and 
expected costs are in FY11 dollars. Procurement dollars for each OARS alternative 
decline dramatically after the first two years due to the fact that the systems will be fully 
acquired. Additional procurement dollars will be needed later in the OARS alternative’s 
life cycles due to the planned acquisition of new technology during the technology 
refresh periods. 
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1. Cost Assumptions 

Due to the fact that the OARS alternative systems have not been developed or 
operated in a combat environment, the procurement, operations, and support costs are not 
yet documented for analysis. As a result, all cost analysis focused exclusively on the 
individual subsystems within the OARS alternatives that would be deployed in a typical 
anti-piracy mission. 

Exhaustive research was conducted to find a Subject Matter Expert (SME) or 
credible source for each OARS subsystem. Data collection consisted of a comprehensive 
research effort spanning various Navy organizations as well as non-military 
organizations. The data collected was comprised of pertinent information that was 
unclassified and available to the public. Actual costs, SME input, confirmed 
specifications, and best effort estimates, provided inputs to the OARS cost models. By 
finding the SMEs for each subsystem, more accurate estimates of subsystem costs were 
made. Additional research provided unit prices and system specifications (including size, 
weight, and speed), as well as capability estimates based on current systems of record. 
The SMEs were able to either provide documentation for exact costs and system 
specifications, or at least a rough estimate for the respective system. Unknown variables, 
such as integration costs, were given best effort analyses to determine reasonable cost 
ranges on existing systems of record. 

During the modeling and simulation phase of the project, the OARS team 
assumed that UAVs would be utilized for only detection and surveillance. It was 
assumed that detection of the UAVs’s presence by the pirates would induce them to halt 
their aggression. For this reason, the cost calculations did not include weapon systems 
aboard the UAV; rather, the weapon system cost was added to the pursuit vessels in the 
form of mounted .50 caliber machine guns. Complete UAV system Life Cycle Costs 
(LCC) would normally be critical to the cost comparisons of each system’s LCCs; 
however, through UAV cost research, the OARS team obtained limited data which 
consists of an hour-by-hour cost comparison for each of the airborne sensors. The 
calculated cost of UAV support was derived from a variety of sources that are 
documented in the references section. Parametric estimates suggest that there would be 
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six UAVs aboard each host vessel, with three flying at all times. This would allow an 
“around the clock” detection capability. The OARS team found that for every flight-hour 
that each UAV was flown, there would be a corresponding operating cost of 
approximately $100 per-vehicle (Defense, Space & Security 2011). 

The sub-systems of each OARS alternative focused on existing mature technology 
and the strategies that have been adopted to support those technologies. The fielding of 
these mature systems allows the OARS system to leverage the existing U.S. Navy supply 
and maintenance infrastructure. It also simplifies the components of training and helps 
facilitate the roles of both the Technical Design Agents (TDA) and the In-Service 
Engineering Agents (ISEA). 

Specific consumables and non-lethal interdiction aids were not included in the 
cost assessment as they are procured as a result of specific threats and provided to system 
operators to carry as a payload. The costs associated with training personnel to operate 
weapon systems and sensor packages were included in our analysis. Consumables like 
ammunition, dye markers, smoke markers, and smoke-screen bombs used during training 
scenarios were included in the life cycle costs as a component of integration and disposal. 


a. Life Cycle Costs 

The total cost of each alternative over their expected lifetime was 
determined through a Life Cycle Cost (LCC) analysis. It provides an estimate of how 
much funding would be required per year to ensure the alternative is fully operational. 
The entire profile of the LCC was categorized in six different costs. These costs are: 
procurement, integration, logistics, operation, maintenance, and disposal. Both 
alternatives had an individual LCC profile that was examined in further detail below. 

The length of each OARS alternative’s life cycle was a result of several 
underlying factors. The entire life cycle can be broken down into two phases with the 
first phase seen as the system’s acquisition. This depends on how quickly the assets can 
be procured and integrated, as well as how much funding will be logically appropriate 
during that time period. The second phase was the actual operational life cycle of the 
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systems. This includes the logistics, operation, maintenance, and disposal costs 
associated with fielding the systems. During each year of the life cycle it was assumed 
that there will be on average 365 missions per year with 24 hour, unceasing service on 
each mission day. The life of the system was evaluated based upon the lifecycles of the 
corresponding subsystems. The mature elements that are weaved into the OARS system 
supported the 15 year fielding plan with technical refresher cycles to be planned in 2025 
and 2030. The end of life for both alternative systems is expected to be 2035. 

2. Cost Analysis and System Specification Methodology 

The rendered alternatives that were deemed feasible were given a comparative 
cost benefit analysis to determine how much capability could be provided and at what 
cost. The cost of each alternative was examined from multiple perspectives. Unit price, 
estimated integration costs, manpower costs, and many other cost components were used 
to determine relative alternative costs. 

Spreadsheet tools were used to capture system data and analyze both 
mathematically and graphically the relationships and relative costs between system 
alternatives. The costs were categorized as procurement costs and life cycle costs. The 
costs of the two OARS alternatives were also broken out by their corresponding 
functional objectives. This data can be found in Appendix I. 

In order to generate a cost estimate for a single alternative, the cumulative costs of 
the subsystems were accounted for as accurately as possible. A 15 year life cycle cost 
(LCC) analysis was performed for each of the two OARS alternatives. A spiral and 
incremental procurement strategy was employed and included as an acquisition cost 
category for the LCC analysis. In 2025 and 2030, an incremental technical refresh was 
scheduled to occur in order to make the OARS lifecycle more realistic. 


a. Preferential Model Results 

Each alternative component (element) was selected by using a multiple 
criteria preference model. Each objective was broken down into key attributes by 

stakeholder preferences. The preference model can be found in Appendix G. 
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The result is that the Zodiac Rigid Hull Inflatable Boat (RHIB) was the 
best alternative to use in both of the OARS systems. Similarly, the same technique was 
also utilized for evaluating what the best lightweight UAV would be. These lightweight 
UAYs were to be used for surveillance in both OARS alternatives. The model resulted in 
the ScanEagle UAV arising as the most preferred, mostly due to its very long endurance 
and range. A preferential model was also developed for the Heavy UAV BAMS system 
that was to be used in the Augmented OARS alternative. This resulted in the MQ-4 
Global Hawk being chosen as the best BAMS alternative to model in the Augmented 
OARS cost analysis. 

3. Cost of Alternative #1, Basic OARS 
a. Procurement Costs 

The total procurement cost of Alternative 1, Basic OARS, was found to be 
$4.78 billion. Costs for Alternative 1, Basic OARS, include funding for combat systems, 
air-borne sensor packages, surface sensors, and weapon systems. Combat systems 
include command and control consoles, as well as communication devices. Table 18 
shows Alternative l’s procurement cost breakdown. The data shows that the bulk of 
Alternative l’s procurement costs center around its use of six individual Littoral Combat 
Ships (LCS) systems. 


Table 18. Procurement Cost Breakdown for Alternative 1. 


Item 

Acquisition 

in $ Millions 

Percentof Total 

Host Vessels: LCS Ships 

$ 

4,080.00 

88.83% 

UAV's 

$ 

1.32 

0.03% 

SH-60s 

$ 

509.00 

11.08% 

Pursuit Vessels: RHIBs 

$ 

0.90 

0.02% 

50Cal MG 

$ 

2.03 

0.04% 


Total Acquisition 


$ 


4,593.25 
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b. Life Cycle Costs 

Table 19 illustrates a similar table that highlights the total LCC of 
Alternative 1. The total LCC of Alternative 1 comes to $15.5 billion. Similar to the 
procurement numbers, the LCS ships and SH-60 Helicopters account for the majority of 
the LCC for Alternative 1. 


Table 19. LCC Breakdown for Alternative 1. 


Item 

LCC in $ Mill ions 

Percent of Total 

Host Vessels: LCS Ships 

$ 

7,980.00 

51.45% 

UAV's 

$ 

773.43 

4.99% 

SH-60s 

$ 

6,048.30 

39.00% 

Pursuit Vessels: RHIBs 

$ 

704.97 

4.55% 

50Cal MG 

$ 

2.54 

0.02% 


15,509.23 | 


Total LCC 


Figure 30 illustrates a breakdown of the total LCC of each of Alternatives 
l’s subsystems. As noted previously, the LCS and SH-60 Helicopter systems account for 
the majority of the costs. 
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Figure 30. LCC Breakdown of Alternative l’s Subsystems. 


Figure 31 shows the funding cycle of Alternative 1 ’s life cycle. The figure 
shows an initial spike in funding with a gradual increase of funding throughout the 
fielding process. The acquisition phase will take place within the first five years. The 
largest amount of funding throughout the entire life cycle will come during the second 
year with nearly $2,591 billion appropriated towards 23% of the total initial procurement 
costs and 20.5% of the initial integration costs. 
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Figure 31. LCC of Alternative 1. 


The fielding phase will begin in year 2020 with approximately $440 
million appropriated to logistics, maintenance, and operational costs. Each year beyond 
that, costs in each area will gradually increase until 2032 with a total cost just over $450 
million. The subsequent year will see a decrease in operational costs due to a reduction 
in training needs. The year 2033 will be the first year that maintenance costs are cut, but 
it will also be the first year that disposal costs are applied. The final year will consist 
solely of disposal and logistics costs. Throughout the entire fielding phase of the life 
cycle, the logistics costs will increase at a constant rate. 

The two additional funding spikes that are shown in Figure 31 will come 
during the technical refresh installments, which were planned to occur in 2025 and 2030. 
Nearly $500 million in technical refresh costs will be spent in the first technical refresh 
period of 2025. Similarly, almost $620 million will be spent during the second technical 
refresh year of 2030. 
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Costs for the acquisition phase and fielding phase in Alternative 1 are 
quite similar even though one phase is five years and the other is 15 years. A distribution 
of cost categories for LCC is displayed on Figure 32. The figure shows that the 
acquisition phase represents 39% of the total costs while the cost for the fielding phase 
accounts for the remaining 61%. Initial procurement and the procurement for the 
technical refresh integration is the largest cost, at nearly $4.8 billion. Logistics makes up 
exactly one third of the total cost with almost $3.6 billion allocated towards it. The 
integration portion is set at 9% which accounts for $730 Million. This correlates well 
with legacy integration efforts utilized during the 10 year development of technology 
upgrades for the Apollo project. This integration effort has been well documented by 
NASA and this data was utilized by the OARS team to help define integration costs of 
the OARS system (National Aeronautics and Space Administration 2011, 678). 
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Figure 32. Alternative 1 LCC. 
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The OARS team determined that the requirements for manning the system 
will consist of utilizing 45 sailors per watch shift. Furthermore, it is assumed that there 
will be three separate watch shifts, each consisting of 8 hour periods (Douangaphaivong 
2004, pg 60). The maintenance and disposal costs are relatively minor compared to the 
other four cost categories, but still need to be considered when determining the overall 
LCC. 


4. Cost of Alternative #2, Augmented OARS 
a. Procurement Costs 

A procurement cost breakdown for Alternative 2 is shown in Table 20. 
The table shows that Alternative 2’s procurement cost is roughly $5 billion. Just as with 
Alternative 1, Alternative 2’s total funding amount is largely affected by the procurement 
cost of the host ship platforms. However, the addition of Alternative 2’s BAMS system 
increases the procurement cost. 


Table 20. Procurement Cost Breakdown of Alternative 2 


Item 

Acquisition 

in $ Millions 

Percent of Total 

Host Vessels: LCS Ship 

$ 

4,080.00 

81.06% 

UAV's 

$ 

1.32 

0.03% 

SH-60 

$ 

509.00 

10.11% 

Pursuit Vessels: RHIBs 

$ 

0.90 

0.02% 

50 Cal MG 

$ 

2.03 

0.04% 

BAMS 

$ 

440.00 

8.74% 


Total Acquisition $ 


5,033.25 


b. Life Cycle Costs 

The breakdown of Alternative 2’s LCC is shown in Table 21. The data 
shows that Alternative 2’s LCC estimated at just under $17.7 Billion. 
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Table 21. LCC Cost Breakdown of Alternative 2. 


Item 

LCC in $ Millions 

Percentof Total 

Host Vessels: LCS Ships 

$ 

7,980.00 

44.90% 

UAV's 

$ 

773.43 

4.35% 

SH-60s 

$ 

6,048.00 

34.03% 

Pursuit Vessels: RHIBs 

$ 

704.97 

3.97% 

50Cal MG 

$ 

2.54 

0.01% 

BAMS UAV 

$ 

2,262.00 

12.73% 


17,770.93 | 


Total LCC 


$ 


A breakdown of costs for each year of Alternative 2 life cycle is shown in 
Figure 33. The second and third years of the acquisition phase account for the two largest 
funding years during the life cycle of the system. Allocation of funding in 2017 will 
come to just over $2.03 billion, while costs in 2018 will come to just over $1.35 billion. 
The fielding phase will begin in year 2020, with $429 million appropriated to logistics, 
maintenance and operational costs. Each year beyond that, costs in each area will 
gradually increase until 2032, which has a total cost just over $497.5 million. The 
subsequent year will see a decrease in operational costs due to a reduction in training 
needs. The year 2033 will be the first year that maintenance costs are cut, but it will also 
be the first year that disposal costs are applied. The final year will consist solely of 
disposal and logistics costs. Throughout the entire fielding phase of the life cycle, the 
logistics costs increase at a constant rate. 

The two additional funding spikes that are shown in Figure 33 will come 
during the technical refresh installments. Nearly $599 million in technical refresh costs 
will be spent in 2025, which is the first year of installation, and almost $824 million will 
be spent during the second installation year of 2030. 
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Figure 33. LCC of Alternative 2. 


Figure 34 shows a breakdown of Alternative 2’s LCC per each of its 
subsystems. The data shows that the majority of the LCCs center around the LCS ships 
and the SH-60 Helicopters, although the introduction of the BAMS UAV adds $2,262 
Billion to the LCC that was not a part of Alternative 1. 
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Figure 34. LCC Breakdown of Alternative 2’s Subsystems. 


A distribution of cost categories for Alternative 2’s LCC is displayed on 
Figure 35. The acquisition phase represents 39% of the total LCC cost while the cost for 
the fielding phase accounts for the remaining 61%. 
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Figure 35. Alternative 2 LCC. 


5. Cost of the Status Quo, CTF-151 

Defining the exact cost of operating CTF-151 was a very challenging task for the 
OARS team. The main issue is that the force structure of CTF-151 fluctuates constantly. 
CTF-151 has matured over its 2 years of operation, but there still is not a baseline force 
structure to have as a point of reference. CTF-151 is a voluntary force comprised of 
many countries that provide ships, aircraft, and support in anti-piracy operations when 
they can. In order to predict the LCC of CTF-151, one would have to know the exact 
number of ships at any point in time. After performing a great deal of research and 
talking with stakeholders, the OARS’ modeling and simulation team decided to model 
CTF-151 as containing 14 ships. Four of the ships were assumed to be USN assets. The 
four U.S. Naval forces were modeled as: 

• DDG-51 Destroyer 

• FFG-7 Frigate (Quantity - 2) 

• LPD-17 Amphibious Transport Dock. 
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CTF-151’s ten remaining coalition vessels were assumed to consist of the 
following ships: 

• Jianwei frigate from PRC (China) (Quantity - 2) 

• Ulsan frigate from South Korea 

• Barbaras frigate from Turkey (Quantity - 3) 

• La Fayette frigate from Singpore (Quantity - 2) 

• Iroquois destroyer from Canada 

• Floreal frigate from France. 

In order to be consistent with the modeling and simulation effort, the cost analysis 
also used this same force structure when estimating the LCC of CTF-151. 

Another reason that estimating the cost of CTF-151 is difficult is the fact that 
most of the assigned ships are from foreign navies and therefore, data on their life cycle 
costs is not readily available. For this reason, the OARS team utilized the same life cycle 
costs that were used in the cost estimation efforts of the two OARS alternatives. These 
life cycle costs were for USN assets, but due to the fact that the foreign navy ships have 
similar sizes and anti-piracy missions, the assumption was made that the foreign ships 
would have similar LCCs. 

Table 22 shows a breakdown of the estimated LCC of CTF-151. The appropriate 
number of helicopters, RHIB boats, and the occasional UAVs were also added to the 
CTF-151’s LCC model. The LCCs of the helicopters were for USN SH-60 Helicopters. 
The OARS team made the assumption that the LCCs of foreign helicopters would be 
similar to the known USN figures. The total LCC was estimated at $17.47 Billion. 
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Table 22. CTF-151 LCC Cost Analysis. 


CTF-151 

Ship 

Qty 

Cost per 
Ship ($B) 

Total 

Acquisition 
cost ($B) 

Added Item LCC Costs 
{RHIB, UAV, Helo){$B) 

Total LCC 
($M) 

DDG-51 

1 

$1.5050 

$1.5050 

$0.0882 

$3,084.59 

FFG-7 

2 

$0.6710 

$1.3420 

$0.0008 

$3,042.00 

LPD-17# 

1 

$1.2050 

$1.2050 

$0.0002 

$1,649.44 

Jianwei 

2 

$0.1540 

$0.3080 

$0.0008 

$697.00 

Ulsan 

1 

$0.1190 

$0.1190 

$0.0002 

$134.70 

Barbaros 

3 

$1.0140 

$3.0420 

$0.0272 

$5,901.48 

La Fayette 

2 

$0.3100 

$0.6200 

$0.0178 

$1,421.31 

Iroquois 

1 

$1.1590 

$1.1590 

$0.0119 

$1,323.12 

Floreal 

1 

$0.1860 

$0.1860 

$0.0122 

$223.97 


Total Acquisition Cost 

$9,645.28 

Total CTF-151 LCC 

$17,477.61 


G. ALTERNATIVE COMPARISON 
1. LCC Comparison 

Figure 36 shows a life cycle cost comparison of both the OARS alternatives and 
CTF-151. CTF-151 was estimated to have the highest life cycle cost. Alternative 1, 
OARS Basic, was estimated to have the lowest LCC. Due to Alternative 2’s addition of a 
heavyweight BAMS UAV, its life cycle cost was greater than Alternative 1. 
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Figure 36. Life Cycle Cost Comparison 


2. Cost-Value Analysis 

a. Decision Matrix 

A decision matrix was used to combine value scores, global weights, and 
raw data and produce total value scores for each alternative based on the most basic 
additive form, or weighted summation, of the value function Multi-Attribute Value 
Theory. In the additive form, the function (U) is split into several different functions (Ui) 
which are strictly increasing real functions. The function (U) can then be retrieved by 
adding the sub-functions (Ui). Global weights were derived from Figure 12 of the QFD 
analysis which states objectives for the system. However, since modeling outputs from 
NSS did not match up exactly to the QFD outputs, estimates were made for global 
weights that best matched up to the objective outputs of Figure 12. These global weights 
were then outlined in Table 23. The measures in the right hand column of the matrix 
were pulled from the NSS modeling MOE outputs. The OARS Augmented system was 
not included in this decision matrix because there were no NSS MOE outputs available to 
analyze. 
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Table 23. Decision Matrix. 


Measure 

Global Weight 

Alternatives 

Unopposed 

CTF 151 

OARS Basic 

UAVTotal Detections 

0.3 

0 

0.7 

1 

UAV Total 

Classifications 

0.3 

0 

0.2 

1 

UAV Cumulative 

Launches 

0.1 

0 

0.32 

1 

Bl ue Assets Overtaken 

0.25 

0 

0.93 

1 

Red Assets Overtaken 

0.05 

0 

1 

0.34 

Total Value Score 

1 

0 

0.58 

0.96 


As seen above, the OARS Basic ranks highest with a Total Value Score of 
0.96. CTF 151 has the second highest total value score of 0.58. Since the OARS Basic 
system scores higher than CTF 151 in four out of the five measures of effectiveness 
(MOEs) it was determined that no sensitivity analysis was required. The goal of both 
CTF 151 and OARS is to deter piracy, so overtaking (red) pirate ships will never be 
assigned a global weight high enough to greatly influence the CTF 151 Total Value 
Score. 


b. Cost versus Value 

Cost-value analysis was performed to consider the overall value, with 
respect to effectiveness. By plotting the total value score obtained from the decision 
matrix in Table 23 against the system acquisition costs from the cost analysis, 
relationships between cost and performance can be derived from the alternatives. When 
an alternative has a higher overall cost and a lower total value score than another 
alternative it is considered “dominated” by that alternative. The OARS Augments 
system was not included in this analysis because the purpose of the analysis was only to 
compare alternatives with available M&S MOE outputs. 
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Table 24. Cost versus Effectiveness Data. 


Alternative 

LCC Cost (US $ billions) 

Total Value Score 

Unopposed 

$0.00 

0 

CTF151 

$17,477.61 

0.58 

Alternative 1: OARS 

Basic 

$15,509.23 

0.96 

Alternative 2: 0AR5 
Augmented 

$17,770.93 

Undetermined 


The data from Table 24 above was then used to create the graph presented 
in Figure 37 below. 
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Figure 37. Cost versus Effectiveness Comparison. 
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Figure 37 illustrates that OARS Basic is the preferred alternative, since it 
dominates the CTF solution with both a lower cost and higher value score. 

G. LOGISTICAL SUPPORT ANALYSIS 

The document OPNAV 4000.85 (1986) addresses U.S. Naval systems logistics 
and breaks down logistics into three areas. These are: Acquisition Logistics, Integrated 
Logistics Support (ILS), and Operational Logistics. 

1. Acquisition Logistics 

Acquisition logistics was simplified by design. Existing commercial UAV 
technology was utilized. The ScanEagle is also a complete system package in itself. It is 
the aircraft, the launcher, the recovery system, and the ground control station. It has been 
fielded for years and flown numerous sorties from land as well as shipboard bases of 
operation. An LCS host vessel was selected because of its mission modularity and 
perfect suitability for UAV operations. The UAV JP-5 fuel requirement is already 
handled by the LCS JP-5 fueling system currently in place. The OARS support strategy 
uses a previously documented Performance-Based Logistics Strategy and makes it easier 
to focus on performance rather than the product. High failure items have already been 
identified for spares. Common Off the Shelf (COTS) items are being used as much as 
possible as well as Naval Inventory Control Point (NAVICP) on-board sparing and Navy 
or Commercial maintenance chains. The use of emerging technologies is discouraged. 

2. Integrated Logistics 

Integrated Logistics Support (ILS) for U.S. Navy Programs involves all of the 

support considerations necessary to ensure effective and economical support for the life 

cycle of ships, systems, and equipment. Because the OARS system consists of existing 

fielded and proven technologies and platforms, the ILS management process will be 

expedited. This process will involve developing support requirements consistent with the 

design and other requirements, integrating these considerations into the design, and 

providing the required support during the system or equipment life cycle at minimum 

cost. The in service engineering group is to also produce all hardware technical 
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documents as well as OARS mission operations, associated systems integration and 
interactions, and all maintenance requirements. These will be produced with contractor 
support using pre-existing commercial documentation, pre-existing LCS module 
documentation, as well as any new original documentation as needed. 

3. Operational Logistics 

Operational logistics consists of logistical and other support activities required to 
support the OARS system during mission operations. OARS is a user maintained system. 
A goal of OARS is to reduce depot level maintenance as much as possible. Initial 
operational and maintenance training will be conducted through the ScanEagle vendor’s 
training services. Eventually the Navy will conduct its own training as system familiarity 
increases. Intermediate depot level maintenance will be provided when necessary. For 
parts support, a Consolidated Shipboard Allowance List (COSAL) will be developed to 
support routine maintenance as well as active mission repairs. Again, the operational 
logistics development will be assisted by the fact that these UAY packages already exist 
in the fleet. 


4. Integration 

As stated above, the LCS host ship concept was chosen because of its modular 

mission construction and its ability to carry enough UAVs needed to carry out the OARS 

swarm UAY missions. It can also support an SH-60 helicopter. There is plenty of room 

for the ground control station as well as launch and recovery platforms. Hangar space 

allows for efficient storage of UAVs in vertical racks. The JP-5 fuel of the ScanEagle 

will be supplied by the existing JP-5 fueling stations. There is space for the multiple 

launchers necessary to get as many UAVs airborne into the air as possible in support of a 

swarm mission requirement. Launchers as well as recovery hooks will be positioned 

along the rail of the LCS. This way, a returning aircraft does not have to cross over the 

deck, which creates a safer operational environment. Since the UAVs, launcher, ground 

control station, and recovery system comes as a package, this subsystem is already 

integrated. This includes the hardware, weapons, communication, and sensor payloads as 

well as the software and databases. All of the above will tend to reduce the overall cost 
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of integration. The cost of labor (number of tasks, number of workers, salary, number of 
man-hours for each task) will be estimated by Subject Matter Experts (SME). 

5. Logistics Support and Supply Chain 

The OARS system will be used to protect vessels of all nations and therefore 
funding for acquisition and sustainment will depend on international assistance. This 
process is defined in DoD 7000.14-R “International Acquisition and Cross Servicing 
Agreements” (2011). The sustainment program will be one of cooperation with all 
member states. As previously mentioned, the OARS system will be using existing DoD 
logistics infrastructure. An ISEA and Logistics center will be identified. It will make use 
of the current parts ordering system, have a Coordinated Shipboard Allowance List 
(COSAL) system in place for on-board sparing for deployment maintenance and repair, 
and follow the current parts storage policies. Depot level maintenance will be reduced as 
much as possible. A repair policy will be established. On-site logistics and repair 
support unique to the ScanEagle subsystem package will be provided by the vendor under 
a service level contract. 

6. Operational and Maintenance Manpower 

The OARS system will have a basic anti-piracy mission module consisting of the 

ScanEagle subsystem package, detention facilities for prisoner transport, and SH-60 

helicopter operations. Typically, an LCS-2 with basic modules requires 40 core crew 

members which includes all enlisted and officer personnel and up to 35 mission specific 

personnel. The OARS system will have four ground control operators per 8 hour shift for 

a total of 13 onboard operators to handle a 24 hour mission, with one as a backup. There 

will be an additional 13 onboard launch and recovery personnel as well. The SH-60 crew 

needs will include 3 pilots, 3 co-pilots and 3 aviation warfare systems operators. 

Initially, training for each OARS system includes UAV manufacturer-provided courses. 

Ten weeks for each UAV operator, four weeks for each maintenance personnel, and an 

additional six week course which will train personnel to become instructors themselves. 

This will allow the Navy to conduct its own training in the future. Students will be 

recruited early enough to serve as each OARS system is readied for service. Student 
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requirements will include computer skills and physical dexterity. The cost of training is 
identified in the life cycle cost estimates in this report. 


7. Disposal and Demilitarization 

Following the guidelines in DOD 4160.21-M “Defense Material Disposition 
Manual” (1997), the OARS Project Manager must document all demilitarization and 
disposal requirements. The cost estimates for this process will be provided early on. The 
demilitarization plans will contain the following information for each item to be disposed 
of: 


1. The item name. 

2. How the item functions when used as intended. 

3. Constituent parts of the item and its components. 

4. How to disassemble and demilitarize the item and its components. 

5. Safety requirements related to the item and to the demilitarization process for 
the item. 

6. Environmental considerations and liabilities associated with the disassembly, 
demilitarization and disposal processes (meets environment, safety and 
occupational health (ESOH) requirements. 

OARS subsystems, equipment, components, and parts may also be removed and 
replaced because of obsolescence, failures, changes, or improvements. These items, once 
removed, may be remanufactured, repaired, reused, refurbished, or demilitarized and 
disposed of at the organizational, intermediate, or depot level maintenance activity. 
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V. CONCLUSIONS AND RECOMENDATIONS 


A. CONCLUSIONS 

After all analysis was complete, the team found that the OARS Basic system 
provides the most detections of pirates and is the cheapest to operate. For these reasons, 
the OARS Basic system is the recommended anti-piracy solution. 


1. Modeling and Simulation Conclusions 

The modeling and simulation effort showed that OARS Basic, which had 130,379 
pirate detections, was better at detecting pirates than the modeled CTF-151 solution, 
which had 91,171 detections. This was a 43% increase in detection. Early detection of 
pirate activity is crucial to its prevention. The stakeholders felt adamantly that weapons 
should not be implemented onto the UAVs, but instead, precise surveillance capabilities 
should be created. This is because pirate interdiction is not occurring in a wartime 
environment, which means that friendly forces cannot engage pirates with deadly force 
unless it is for self-defense purposes. The 43% increase in detections equaled 39,208 
more detected pirates. 

The modeling results did show that CTF-151 had more pirate arrests than the 
OARS Basic system, but this was an expected result due to the fact that the pirates were 
less deterred and freer to commit acts of piracy. The OARS Basic system’s use of 
lightweight UAVs gives it superior surveillance and reconnaissance capability, as well as 
a greater ability to capture incriminating evidence of pirate acts. The addition of video 
surveillance data will allow more pirates to be prosecuted for their acts of piracy. 

2. Cost Analysis Conclusions 

The total Life Cycle Cost of the two OARS alternatives and the CTF-151 solution 

was estimated. After the cost analysis was complete, the OARS Basic system was found 

to be the cheapest alternative, and had a life cycle cost that was 13% cheaper than the 

CTF-151 solution. The OARS Basic system was cheaper because it utilizes UAV 

technology to cover a greater area and therefore, requires fewer high-value ships than the 
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CTF-151 solution. The OARS Basic system is also comprised of the newer Littoral 
Combat Ships (LCS) that have a much smaller life cycle cost than today’s naval ships. 

3. Decision Metrics Conclusions 

Figure 38 shows the decision metrics matrix that defines the modeling and 
simulation Measures of Effectiveness (MOE) as well as their global weight. Due to the 
crash of the modeling and simulation software database, the Naval Simulation System 
(NSS), all modeled scenarios and results were deleted and lost before the OARS team 
had a chance to model the Augmented OARS alternative. For this reason, the decision 
matrix only illustrates modeling MOPs for the CTF-151 solution and the OARS Basic 
system. The OARS Basic system received a total value score of 0.96 which was almost 
40% larger than CTF-151’s value score of 0.58. 


Measure 

Global Weight 

Alternatives 

Unopposed 

CTF 151 

OARS Basic 

UAV Total Detections 

0.3 

0 

0.7 

1 

UAV Total 

Classifications 

0.3 

0 

0.2 

1 

UAV Cumulati ve 

Launches 

0.1 

0 

0.32 

1 

Blue Assets Overtaken 

0.25 

0 

0.93 

1 

Red Assets Overtaken 

0.05 

0 

1 

0.34 

Total Value Score 

1 

0 

0.58 

0.96 


Figure 38. Decision Metrics. 

4. Cost Value Analysis Conclusions 

Figure 39 below shows the cost versus effectiveness graph of the OARS Basic 
system and CTF-151. The graph shows that the OARS Basic system was both more 
effective and less costly than CTF-151. 
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Figure 39. Cost versus Effectiveness Comparison. 


5. Summary 

After all analysis was complete, it was found that the OARS Basic system 
provides the most detections of pirates and is the cheapest to operate. For these reasons, 
the recommendation is the OARS Basic system. 


B. RECOMMENDATIONS 

1. Recommended Areas of Future Research 

The analysis conducted by the OARS capstone team provided great insight into 
the effectiveness of UAV technology in the deterrence of piracy within the Gulf of Aden. 
With that being said, there are still some areas of further research that can be pursued to 
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provide a greater understanding of all factors involved in anti-piracy operations. The 
future research categories are: modeling and analysis, operational, and technical. 


a. Modeling and Analysis 

The modeling and analysis areas of future research identify topics that can 
be further researched that will provide greater insight into the OARS system’s 
effectiveness in anti-piracy missions. 

• Due to the crash of the Naval Simulation Software (NSS), the Augmented 
OARS system was not modeled. The benefits of adding a Broad Area 
Maritime Surveillance (BAMS) UAV are still unknown, and further 
modeling and analysis on these benefits could provide insight into the 
Augmented OARS effectiveness in anti-piracy operations. 

• Further research could be conducted to help better pinpoint the average 
force structure of CTF-151 and in turn, a better life cycle cost estimation. 
Due to the fluctuation of CTF-151’s force structure and its unique use of 
ships from many countries, estimating its’ life cycle cost was difficult. 

b. Operational Areas 

The operational areas of future research focus on the operational areas 
where the OARS system may be utilized worldwide. These potential research topics will 
provide more insight into the OARS system’s ability to be used to fight piracy 
worldwide. 

• Additional operational areas of anti-piracy operations need to be analyzed. 
The OARS team focused on deterring piracy within the Gulf of Aden, 
which provides a unique, narrow corridor of operation. However, Somali 
piracy has been expanding into the Indian Ocean and therefore, use of the 
OARS systems in a more open ocean environment should be examined. 

c. Technical Areas 

The technical areas of future research mostly define subsystems of the 
OARS systems that require more research to define their validity in anti-piracy missions. 

• Evaluation of the MQ-8B Fire Scout Vertical Takeoff Unmanned Aerial 
Vehicle (VTUAV) as a replacement to the SH-60 Helicopter for anti¬ 
piracy missions. The OARS team ruled out the use of the Fire Scout due 
to the fact that it did not aid in the detention and capture of pirates. 
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however, the Fire Scout is significantly less costly to operate and deserves 
further research into its use in anti-piracy operations. 

• Further research needs to be conducted on the host vessel’s ability to 
intercept and monitor the pirates’ handheld satellite communications and 
Global Positioning Systems (GPS). The pirate’s use of technology was 
limited, but the ability of the commander to monitor this information 
would be a crucial asset to anti-piracy operations. 
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APPENDIX A STAKEHOLDER COMMENTS 


Captain Brown 

• CO of CG-64 Captured 38 suspected pirates and one mothership 

• UAVs should not have lethal force 

• Host vessel should maintain a chain of evidence (i.e. video record of 
suspected pirates dumping their weapons overboard) for the detention and 
prosecution of pirates. 

LT Cook 

• UAVs should not have lethal force 

• Evidence collection necessary and demanding 

• Identification of pirates was very important and made the boarding party 
much safer 

Captain Place (ret USN) 

• UAVs need high grade JP fuel 

• IRIDIUM use for Command and Control 

• AIS Automatic Identification System 

• LCS radars are good for tracking 

• Deploy EO IR Systems for ID 

• ScanEagle 80 nm range EO IR capability 

• Fire Scout is modular and helpful 

• BAMS goes to $120M 

• ScanEagle with 6 birds is $5M by INSITU 
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APPENDIX B 


FUNCTIONAL FLOW BLOCK DIAGRAM (FFBD) 
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Figure 40. FFBD 1.2, ‘Underway Replenishment’ 
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Figure 41. FFBD 2.1, ‘Detect’ 
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Figure 42. FFBD 2.1, ‘Fix/Classify’ 
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Figure 44. FFBD 2.4, ‘Track’ 
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Figure 47. FFBD 4.1 ‘Intercept’ 
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APPENDIX C MODELING SCENARIO NUMBERS 
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French Frigate 

1 


Canadan Destoryer 

1 




French Frigate 

1 

Boardina RHtB Boats 

IB 




DDG SI Class 

2 


Boardina td-ttB Boats 

16 

LCS Class 

2 


DDG 51 Class 

2 

LPD 17 

2 


LPD 17 

2 

Chinese Frigate 

2 


Chinese Frigate 

2 

Korean Frigate 

2 


Korean Frigate 

2 

Tirkey Frigate 

2 


Tirkey Frigate 

2 

Signapore Destroyer 

2 


Signapore Destroyer 

2 

Canadan Destoryer 

2 


Canadan Destoryer 

2 

French Frigate 

2 


French Frigate 

2 






l/AV-Optionl 

16 


UAV-Qpdwnl 

? 

Scan Eagle (LCS) 

9 


Scan Eagle (Dynalifter 

2 

Scan Eagle (DDG) 

3 


Scan Eagle (DDG) 

3 

Scan Eagle (LPD) 

4 


Scan Eagle (LPD) 

4 






UAV-QptiDn2 

3 


UAV Option 2 

z 

UAV2(LCS) 

4 


UAV 2 (Dynalifter) 

2 

UAV 2 (DDG) 

2 


UAV 2 (DDG) 

2 

UAV 2(LPD) 

3 


UAV 2(LPD) 

3 






UAVOptmtl 

? 


UAVOption3 

z 

UAV 3 (LCS) 

4 


UAV 3 (Dynalifter) 

2 

UAV 3 (DDG) 

2 


UAV 3 (DDG) 

2 

UAV 3 (LPD) 

3 


UAV 3 (LPD) 

3 






Land Bases. 

1 


LandBases 

1 

5th Fleet HQ- Bahrain 

1 


5th Fleet HQ- Bahrain 

1 






Refuetina Bases. 

2 


RefaeUna Bases 

2 

□idkai 

1 


DrAkai 

1 

Quatar 

1 


Quatar 

1 
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APPENDIX D RISK MANAGEMENT 


A. RISK MANAGEMENT STRATEGY 

Risk can be defined as . .the net negative impact of the exercise of vulnerability, 
considering both the probability and the impact of occurrence” (NIST, 1). Risk 
management is a continuous process that is accomplished throughout the life cycle of a 
system. It is a process that encompasses risk identification, analysis, assessment, 
mitigation planning, mitigation implementation, monitoring, and tracking. Early 
identification of the OARS project risks allowed for early implementation of mitigation 
strategies and therefore improved the likelihood of the project achieving its stated 
objectives. Risks were identified during project analysis, established and reviewed with 
primary stakeholders, and continuously monitored and managed throughout the OARS 
project’s lifecycle. Risks were managed by order of criticality and the data obtained was 
documented. The risk management IPT created a risk management strategy that 
illustrated the process in which the OARS team used to mitigate risks. 

A risk mitigation strategy was developed to assist in the mitigation process in 
order to determine whether or not an improvement was acceptable. The strategy defined 
how risks were managed throughout the lifecycle of the project. For this strategy, there 
were three stages. These stages were: 

1) Risk Assessment. 

2) Risk Control. 

3) Risk Review. 

Proper processes were instilled in the OARS’ risk management effort to ensure 
that sufficient communication of risk information was provided to all involved. Model 1 
below displays the OARS Team’s Risk Management Strategy along with the three stages 
involved. The OARS risk management process was initiated and used to assess, mitigate 
and review the risks. If in the control stage, the risk is unacceptable, it returned to the 
assessment stage for reevaluation and/or removal. If the risk is accepted, it moved 
forward through documentation and review. During the review, if a risk was discovered 
that was not previously anticipated, the risk was passed backwards to the Risk Control 
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stage and if necessary, back to the Risk Assessment stage. Each stage of the risk 
management process will be discussed, beginning with Risk Assessment. 

Risks were managed by order of criticality and the data obtained was 
documented. There were three areas of importance in the OARS team’s risks. The areas 
of importance were as follows: Technical Risk, Model Risks, and Project Risk. Once the 
risks were established, a Risk Prioritization Matrix was then developed. Below is a 
breakdown of the biggest risks that were identified during the project, as well as their 
mitigation strategies. 




Figure 49. Risk Management Process. 

1. Stage 1 Risk Assessment 

Risk assessment is the identification, analysis, and evaluation of the levels of risks 
involved in a situation as shown in Model 2 below. It is the first stage of the risk 
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management process that will determine whether or not there is an acceptable level of 
risk for the OARS system. 



Saga 1 


Figure 50. Stage 1, Risk Assessment. 


Risk Identification 


a. 


Risk identification is the activity that examines each element of the project to 
identify associated cause, begin documentation, and set the stage for the successful 
OARS risk management process. To identify any risks of the OARS project, the “what 
can go wrong” questions were asked. To answer the questions, “IF - THEN” statements 
were formed. A condition-to-consequence risk statement was generated. For example, 
IF Coalition forces do not acquire pirate identification in time, THEN the probability of 
pirate boarding increases. A table containing the top eight risks was developed using this 
method and is shown below. The risk number values were taken from the Risk Reporting 
Matrix (RRM), located in Section 1.1.1.2. Once the risks were identified, the next step in 
the process was to complete a risk analysis of the system. 
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Table 25. Identified Risks with Partial Mitigation, 


No. RISK Impact Likelihood Risk Type Manage/Mitigate 



IF OARS cannot complete the M&S activity , 




Overcome lech ideal NSS 

difficulties with SME Metron 

1 

TURN system will lark data for consideration 
of alternative* 

C 

90** 

Model 

2 

IF Coalition force* do not acquire pirate 
identification hi time, THEN (lie probability of 
pirate hoarding increase* 

c 

30** 

Mission 

Have capability to sense targets 
of Interest 


IF Differential GPS mounted on UAV or 




Use alternative method to 
recover UAV (Net) 

3 

Skyhook is damaged while in operation. THEN 
recovery of UAV w ould be difficult 

S 

20° * 

Technical 

4 

IFOARS system to system integration has 
i ncoin pa t i bill ty pro Idem* THEN a fail < 1 re could 
ocelli' causing loss of craft. 

Mo 

40°* 

Technical 

Select a proven 

soft wa re ha id ware pa ck age 


IF Coalition have proprietary Issues with 




Build equipment using 

5 

technology’. THEN the objectives for the effort 

Mi 

5% 

Mission 

International standards (ISO) 


will not he fulfilled 




for quality and manufacturing 


IF Coalition lacks ability to adapt to change in 




Acquire FOUO Intel on pirate 

6 

pirate tactics and weapons, THEN increased 

C 

30 a * 

Opera tlonal 

tactics and w eapon acquisition 


loss of assets will occur. 




to monitor pirate activity 


IF Multiple attacks to several commercial ships 
occur at the same time, THEN there could be a 
loss of situation awareness and safety to 




Review lech ideal specifications 


c 

50 a * 

Technical 

that has contingency for sw arm 
effect 

Civilian vessels Is compromised 

8 

IF new capabilities and requirements are 
added to the OARS system, THEN more testing 
will be required, causing possible delay in 
project completion 

s 

20 a * 

Technical 

Cost 

Involve stakeholders In future 
planning for Intel. Delay code 
freeze until latest possible time 


IF OARS cannot be fully supported by 




Use of IMPRINT and 

9 

necessary manpower due to Injury, THEN the 
ability to operate OARS efficiency will be an 

s 

10*4 

Personnel 

Involvement of HSI early in the 
development process. 


issue 




IMPRINT-N for Navy 


IF there Is limited capability for seenailos in 





10 

M&S, THEN the ability to see full measure of 
OARS capability will be Limited as well. 

Mo 

30 a * 

Model 

Accept risk 


IF OARS lack stakeholder requirements. 




Ret i ieve sufficient st ak eh old ei 

11 

THEN the actual recommended solution may 

Mi 

10** 

Project 

input in the requirement 


not correctly address the need 




solid tall on process 

12 

IF deployment schedule Is to stringent, THEN 
OARS system may not be mission capable 

Mo 

20** 

Project 

Rem if nt schedule to follow 
i nci einei i tal dept oy men t 

13 

IF budget cannot allocate funding to OARS 
system by procurement date, THEN system 
cannot he implemented 

S 

50*o 

Project 

Acquire proper all procurement 
and operations support 


Mi = Minor Mo = 

Moderate 

S — Serious 

C — Critical 



b. Risk Analysis 

Risk analysis involves identifying the most probable risks to the project and 
analyzing the related vulnerabilities to these risks. The intent of risk analysis was to 
answer the question “How big is the risk?” This is accomplished by: 

• Considering the likelihood of the risk occurrence, 

• Identifying the possible consequences/impact for this project in terms of 
schedule, and 
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• Identifying the risk level using the Risk Reporting Matrix shown in Figure 
51 below. 

A Quantitative risk assessment requires calculations of two components of risk: 
the consequence/impact of the potential loss, and the probability that the loss will occur. 
The OARS team defined the criteria for likelihood and consequence or impact for 
evaluating the project’s risk. The use of the Risk Reporting Matrix below displayed the 
level of the risks identified within the project. The level of risk was then documented 
with a consequence/impact ranging from negligible to critical. In Figure 1, the level of 
likelihood of each risk was established using specified criteria. The level of likelihood 
for the OARS project ranges from “remote” to “near certainty.” For example, if the risk 
has an estimated 50 percent probability of occurring, the corresponding likelihood is 
“likely.” 


Technical Risks 

1. Modeling & simulation 
2« Target identification failure 

3, Launch & recovery 

4. System integration 

5* Interoperability of system and coalition 
6. Change in pirate tactics and weapons 
1 , Pace of operation 

8. Adding new capability and requirements 
9* Manning 

10.Limited scenario capability 
1 LLack of stakeholder requirements 
12.Deployment schedule 
13*Cost projection 



Figure 51. OARS Risk Matrix. 

To analyze the risks even further, the OARS team also used fault trees to illustrate 
the undesired state of the system. The use of fault trees assisted with the determination of 
system functional failure probability. 
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c. Fault tree analysis (FTA) 

The fault tree was one of the methodologies used for each of the OARS risks. It 
helped to determine whether or not the risk was acceptable. This tool assumes failure of 
the functionality of a product or process (Kirupakar 2011). The results were represented 
pictorially in the form of a tree of fault modes. This was used to investigate complaints 
or deviations, and allowed the team to fully understand their root cause and ensure that 
intended improvement would resolve the issues and not cause any other problems 
(Kirupakar 2011). A good example of this tool is provided below in figure 3. 



Figure 52. Fault Tree Analysis of Identification Failure Risk. 


Figure 3 shows a representation of a fault tree for the first technical risk of the 
OARS system. This tree introduces complex units known as “gates,” which serve to 
allow or hinder the passage of fault logic up the tree. The gates show the relationships of 
events that are needed “higher” events to occur (Vesely 1981). In this case, 

“Identification failure” is the higher event, which is the output of the ‘and’ gate. The 
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lower events are the inputs to the ‘and’ gate. The ‘AND’ gate is used when the output 
occurs if all the inputs are true. The ‘OR’ gate is used when the output occurs if at least 
one of the inputs are true. The ‘basic event’ symbol is used when initiating a fault 
requiring no further development. 

d. Risk Evaluation 

Risk evaluation is the process of analyzing potential losses from a given risk 
using a combination of known information about the situation, knowledge about the 
underlying process, and judgment about the information that is not known or well 
understood. The OARS team was assigned to each identified risk, with priority given to 
the most critical risks first. The OARS team’s risk evaluation involved assessing existing 
controls and their adequacy relative to the potential threats. 

2. Stage 2 Risk Control 



a. Risk Mitigation Plan 

The objective of the OARS risk mitigation efforts was to lower the probability of 
the risk event occurrence, and to explore risk response strategies for the high risk items 
identified in the qualitative and quantitative risk analysis. The process identified and 
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assigned OARS IPTs to take responsibility for each risk response. It ensured that each 
risk requiring a response had an owner. The intent of risk mitigation planning was to 
answer the following question: “What is the program approach for addressing this 
potential unfavorable consequence?” One or more of the following mitigation options 
may have applied: 

1. Avoid risk by eliminating the consequence/impact, 

2. Control the likelihood and consequence/impact, 

3. Transfer the risk, 

4. Accept the level of risk and continuing on the current project plan. 

Table 26 represents some of the tools and techniques that the OARS team used to 
assist in reducing the likelihood of the risks occurring. 


Table 26. Risk Tools. (From Engineering Risk Benefit Analysis. DoD Risk 
Management V03-25-201). 


PERSONNEL 

PROCESS 

TECHNOLOGY 

TRAINING 

DEFINE REQUIREMENTS 

USE PROVEN TECHNOLOGY 

HIRING/PROMOTION 

DESIGN REVIEWS 

MOCK-UPS & PROTOTYPING 

COMMUNICATION 

RIGOR 

TECHNOLOGY MATURATION 

LEADERSHIP 

TEST PROGRAM 

REDUNDANT DESIGN 

KNOWLEDGE SHARING 

TRADE STUDIES 

ROBUST DESIGN 


MODELING & 

OPEN SYSTEMS 


SIMULATION 



b. Risk Mitigation Implementation 

After the risks had been analyzed and documented according to their levels of 
priority in the mitigation plan, the development and integration of the corresponding risk 
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mitigation strategies followed and were referenced against the previously prepared risk 
management plan. 

c. Risk Acceptance 

The concept of risk acceptance asked the question, “How safe is safe enough?” 
The OARS team collaborated with its stakeholders in determining the acceptable level 
with which some risks within the project would be allowed. 

2. Stage 3 Risk Review 



Figure 54. Stage 3 Risk Review. 
a. Risk Monitoring and Tracking 

Risk monitoring and tracking “is the process for tracking identified risks, 
monitoring residual risks, identifying new risks, executing risk response plans, and 
evaluating their effectiveness throughout the project life cycle" (Project Management 
Institute 2008, 237). 

The OARS risks were regularly monitored and tracked through the lifecycle of the 
project. The OARS team monitored and tracked the risks in intervals of weekly 
meetings. The meetings addressed the implementation of risk handling actions and their 
impact to the project. The OARS team monitored risk mitigation plans and their 
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progress, reviewed and updated risk status, and communicated the risks to all affected 
stakeholders. The status of each risk was displayed on the Risk Reporting Matrix 
discussed earlier in this document. The OARS team communicated any changes in the 
risks and mitigation plan with the appropriate personnel. 

B. OARS RISK ANALYSIS 

Risks were managed by order of criticality and the data obtained was 
documented. There were three areas of importance in the OARS team’s risks. The risks 
were as follows: 1. Technical Risk, 2. Model Risks, and 3. Project Risk. Once the risks 
were established, then a Risk Prioritization Matrix was developed. 

1. Technical Risks 

Risk #7: Pace of Operation. The inability of OARS to handle simultaneous attacks 
would cause loss of situational awareness. Mitigation Strategy: Review technical 
specifications which have a contingency plan for swarm effect and implement when 
necessary. 

Risk #6: Change in Pirate Tactics (OARS inability to adapt to the change in 
opponent tactics resulting in mission failure). Mitigation Strategy: Acquire “For Official 
Use Only” (FOUO) intelligence on pirate tactics and weapon acquisitions to monitor 
pirate activity in real time. 

Risk #2: Target Identification Failures. This had a large potential for OARS to be 
unable to detect/identify pirates in a timely manner causing mission failure. Mitigation 
Strategy: Utilize proven capability to sense targets of interest with backup contingencies. 

2. Model Risks 

Risk #1: The M&S team was new to the NSS modeling & simulation program and 
had very little experience, requiring oversight from knowledgeable associates. Hence, 
actual model results may not be accurate, resulting in an improperly recommended 
solution. Mitigation Strategy: The team attempted to mitigate this problem by 
proactively meeting 2-5 times a week to facilitate rapid learning and model construction. 
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Risk #10: NSS Software Limitations. The OARS NSS model was very limited in 
contrast to what scenarios the M&S team wanted to simulate. The objective was to 
model the entire Indian Ocean, but only the Gulf of Aden was modeled because of time 
restrictions and program capabilities. Mitigation Strategy: Accept the Risk. 

3. Project Risks 

Risk #8: Requirements/Capability Change. This could change the scope, 
requirements, and capabilities incurring delays and increased development cost. 
Mitigation Strategy: Involve stakeholders in future planning for intelligence and delay 
code freeze until latest possible time 

Risk #11: Lack of stakeholder requirements. The OARS project had few 
participating stakeholders. Stakeholder feedback was very limited. Hence, the 
recommended solution may not correctly address the actual needs and requirements of 
the stakeholders. Mitigation Strategy: To reduce this risk, the Stakeholder IPT made 
many attempts to retrieve stakeholder feedback in the requirements solicitation process. 
It is recommended that any future development of this proposal re-solicit stakeholders for 
further feedback. 

Risk #12: Deployment schedule. The OARS project has a projected deployment 
date of 2020. Because of this tight deployment schedule, OARS may not be mission 
capable by this date, thus failing to meet the needs of the stakeholders. Mitigation 
Strategy: Re-orient the deployment schedule to follow an incremental deployment 
schedule. Hence, incorporate additional UAVS and increase capabilities as successful 
fielding occurs. 

Risk #13: Cost projection. Due to a decrease in weapon system budget allocation, 
obtaining the expected costs for the OARS system may be at risk through 2016, which is 
the projected congressional authorization. Mitigation Strategy: Acquire proper Ally 
procurement and operations support. 
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4. Risk Prioritization Matrix 

Now that the three categories of risks have been established, a prioritization 
matrix of those categories was developed in order to show the overall status of the risks 
of the OARS system. 


Overall Risks 

1. Technical Risks 

2. Model Risks 

3. Project Risks 


Nw Cenjmty 


Highly Lively 

^3 

Q 

O Likely 

£ [HhSO^ 

"3 


— 1 Unlikely 

{11-40*1 


Remote 


C on sequ en ce.'lmpa ct 



3l 


Negligible Minor Sttiftitl CtibUl 


Figure 55. OARS Risk Matrix. 
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Risk # 1-Modeling and Simulation 


Risk Owner: OARS 

Description: M&S completion with satisfactory scenario data 
collection, analysis, and Capstone insertion 

Mitigation Steps: 

1. Overcome technical MISS difficulties with SME Metron. 

2. Complete M&S CTF data run and collect data quickly 

3. a. Complete M&S alternate software application attempt 
b. Complete Data Analysis with retrieved Data 

4. If alternative M&S successfully runs, complete data 
analysis to be inserted in the Capstone project. 


Category: 90% - C 



0oei5*q«r*e 



Mi = Minor Mo = Moderate S = Serious C = Critical 

Figure 56. Risk #1: Modeling and Simulation. 


Risk# 2-Target Identification Failure 


Risk Owner: OARS 

Description: For the identif ication of a target, the radars, 
themselves, must be capable of very accurately determining the 
positions of the targets. 


Mitigation Steps: 

1. Have capability to sense targets of interest 

2, Assume risk with procedures that dictate visual 
identification 


Category: 30% - C 






Mi = Minor Mo = Moderate S = Serious C = Critical 


Figure 57. Risk #2: Target Identification Failure, 
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Risk# 6-Change in pirate tactics and weapons 


Risk Owner: OARS 

Description: Have the capability to adapt to change in pirates 
tactics and weapons in real time 

Mitigation Steps: 

1. Acquire real time FQUO Intel on pirate tactics and 
weapon acquisition and activity* 

2. System respond to an attack prior to boarding. 

3. Encrypt codes in radio communication for security 

4. Use of NATO and US platforms to cover larger areas 
during patrols 

5. 24/7 Surveillance 


Category: 30% - C 



ConscqwKf 



Mi = Minor Mo = Mode rale S = Serious C = Critical 

Figure 58. Risk #6: Change in Pirate Tactics and Weapons. 


Risk# 7-Pace of Operation 


Risk Owner: OARS 

Description: Must maintain situation awareness during 
multiple attacks to several commercial ships occurring 
at the same time. 


Mitigation Steps: 

1. Review technical specifications that has contingency 

for swarm effect 

2* Training of anti-pirate personnel, 

3.. 24/7 Surveillance 

4, Stagger patrol during calmer weather 


Category: 50% - C 






Mi = Minor Mo = Moderate S = Serious C = Critical 

Figure 59. Risk #7: Pace of Operation. 
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APPENDIX E HOST SHIP COST COMPARISON 


As discussed in Chapter II, Problem Definition, the Concept of Operations 
(CONOPS) of the OARS system includes coverage of 1.1 million square miles of ocean. 
In order to accomplish this feat, six host ships will need to be utilized. The OARS 
system’s requirement for six host ships can be fulfilled by the use of many different naval 
vessels, including: LPD, LHA, LCC, CG, DDG, and FFG ships. However, the limited 
number of LPDs, LHAs, and LCCs in the U.S. Naval Fleet precludes the use of more 
than one of these capital ships in the Gulf of Aden OARS system. A procurement cost 
comparison to this six-ship system in the Gulf of Aden is presented in both Table 27 and 
Figure 60. 


Table 27. Host Ship Combination Count for each Alternative. 


Combo* 

LCS 

LPD 

LHA 

LCC 

CG 

PPG 

FFG 

1 

6 







2 


1 



1 

4 


3 






3 

1 

4 





* 

2 

2 

5 


* 





3 

5 



l 



4 


7 



1 


1 

3 

1 

S 



1 


1 

2 

2 

9 



1 


1 

1 

3 

10 




1 

1 

4 


n 






3 

* 

12 






2 

2 

13 




* 

* 

1 
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Procurement Cost in Millions of US Dollars 
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1 2 3 4 5 6 7 5 9 10 11 12 13 

OARS Host ship combination Cost Reference # 


Figure 60. Costs of Alternatives to Host Ship Procurement. 

Figure 60 shows that the procurement cost of Combination 1, which consists of 
six Littoral Combat Ships (LCS), is the least costly solution. For this reason, the OARS 
team utilized six LCS vessels in both of the OARS alternatives. 
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APPENDIX F TABLES USED IN COST ANALYSIS 


Table 28. Functional Objective Area of Interest for OARS Sub-Systems. 


Item 

Quantity 

Detection 

C-3 

L&T 

Engage 

LCSShip 

6 


X 

X 

X 

UAV's 

9/12*6 

X 




SH-60 

12 

X 

X 

X 

X 

RHIB 

12 


X 


X 

50 Cal MG 

12 




X 

BAMS 

2 

X 

X 

X 



Table 29. 2010 Inflation Rates from a NAVAIR Procurement, (taken from 
NCCA Inflation Indices 2010) 

APN = Aircraft Procurement. Navy (1506) 


Base Year = 2010 2/24/2009 


Fiscal 

Year 

Inflation 
Rate % 

Raw 

Index 

Weighte 
d Index 

Budget 

Year 

Index 

Budget 
Year 
Inflation 
Rate % 

1996 

2 00% 

0 7901 

0 8078 

0 7890 

1 40% 

1997 

1 80% 

0 8043 

0 8148 

0 7957 

0 86% 

1998 

0 70% 

0 8100 

0 8242 

0 8050 

1 16% 

1999 

0 80% 

0 8164 

0 8348 

0 8153 

1 28% 

2000 

1 40% 

0 8279 

0 8459 

0 8261 

1.33% 

2001 

1 80% 

0 8428 

0 8560 

0 8360 

1 19% 

2002 

0 80% 

0 8495 

0 8668 

0 8466 

1 26% 

2003 

1 00% 

0 8580 

0 8841 

0 8635 

2 00% 

2004 

2 00% 

0 8752 

0 9074 

0 8863 

2 64% 

2005 

2 80% 

0 8997 

0 9330 

0 9112 

2 81% 

2006 

3 10% 

0 9276 

0 9588 

0 9364 

2 77% 

2007 

2 70% 

0 9526 

0 9812 

0 9583 

2 33% 

2008 

2 40% 

0 9755 

0 9959 

0 9726 

1 50% 

2009 

1 50% 

0 9901 

1 0089 

0 9853 

1 31% 

2010 

1 00% 

1 0000 

1 0239 

1 0000 

1 49% 

2011 

1 40% 

1 0140 

1 0413 

1 0170 

1 70% 

2012 

1 70% 

1 0312 

1 0599 

1 0351 

1 78% 

2013 

1 80% 

1 0498 

1 0790 

1 0538 

1 80% 
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Table 30. Collection of Procurement and LLCs by Reference Year (various). 


Item 

Acquisition $ M or K/unit 

O&S $ M or K / unit 

Quantity 

Ufecyde 

O&S 6 sys/yrSM 

LCC 6 SyS SM 

fy Price 

LCS Ship 5 

680 M/ship 

43 M 

6 

25 years 

258 

7950 

FY10 

UAV's J ' li 

7 M/12 

$3,942 M 

6 

15 years 

47.304 

793.56 

FY 06 

SH-60 5 

42.417 M/A .C 

28 M/ a/c 

! 

12 

4,5 years 

336 

5549,004 

FY04 

MQ-8B 7 

16.2 M 

1,97 M 

12 

10 years 

23.65 

549.2 

FY06 

RHIB* 

100K 

3.65 M/yr 

12 

10 years 

43.8 

658,2 

FY11 

50 cal MG 5 

14.QQk/Gun 

2,Bk/gun 

12 

15 years 

0,0336 

0,504 

FY11 

BAMS 10 

220 M 

169. S3 

2 

15 years 

339.6626667 

2,547.47 

FY11 

50 Cal Ammo :t 

1.85 K/1,00 0=1.85 M/Million 

M/A 

1M 

15 years 

LBS 

1,85 

FY 11 


The above table was used to collate the data from various element procurement and then life-cycle costs by reference year 
(various). 


Table 31. Costs Set to Base Year FY11 from Procurement Costs and LCCs. 


item 

Acquisition $ M or K/unit 

O&SSM or K/unit 

Quantity 

Lifecycle 

O&S 6 sys/yr $M 

LCC 6 sys SM 

FY Price 

LCS Ship* 

689.52 M/ship 

43.602 M 

6 

25 years 

261.612 

8004.18 

FY11 

uav’s 4,u 

7.65 M/12 

$4.31 M 

6 

1 .. 

15 years 

51.71 

775.61 

FY 11 

SH-60* 

49.14 M/A.C 

32.44 M/ a/c 

12 

4.5 years 

389.26 

5838.95 

FY11 

MQ-8B* 

17.71 M 

2.15 M 

12 

10 years 

25.85 

600.32 

FY11 

RHIB 5 

100K 

3.65 M/ yr 

12 

10 years 

43.8 

658.2 

FY11 

50 Cal MG 5 

14.00k/Gun 

2.8k/gun 

12 

15 years 

0.0336 

0.504 

FY11 

BAMS 10 

220 M 

169.83 

2 

15 years 

339.6626667 

2,547.47 

FY11 

50 Cal Ammo 11 

1.85 K/l,000=1.85 M/ Million 

N/A 

1M 

15 years 

1.85 

1.85 

FY 11 

,c 


The above table was used to inflate costs to a base year FY 2011 from various element procurement and then life-cycle costs. 
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Table 32. Alternative 1 Cost per Life Cycle Year. 



2016 

2017 

201S 

2019 

2020 

2021 

2022 

2023 

2024 

2025 

2026 

2027 

2023 

2029 

2030 

2031 

2032 

2033 

2034 

2035 

Totals 

Procurement 

£ 

1.000 

$ 

1,970 

$ 

1,000 

£ 

600 

£ - 

£ - 

$ - 

5 - 

£ - 

5 630 

g - 

g - 

g - 

g - 

£ 720 

g - 

£ - 

$ - 

£ - 

$ - 

5 

5,967 

Integration 

£ 

g 300 

g 600 

$ 

360 

$ 140 

£ - 

5 - 

$ - 

5 - 

5 - 

£ - 

$ - 

s - 

£ - 

£ - 

£ - 

£ - 

£ - 

$ - 

5 - 

$ 

1.400 

Logistics 

$ 

S 

$ 

$ 

- 

$ 296 

$ 297 

$ 293 

$ 299 

$ 300 

$ 301 

$ 302 

$ 303 

$ 304 

$ 306 

$ 303 

$ 310 

$ 312 

£ 313 

£ 313 

$ 313 

S 

4,S94 

Operations 

£ 

g 

$ 

$ 

- 

$ 210 

$ 211 

5 212 

5 213 

$ 214 

5 215 

g 216 

$ 217 

$ 213 

£ 219 

$ 220 

$ 221 

£ 212 

£ 120 

£ 60 

£ - 

2,949 

Maintenance 

£ 

g 

$ 

$ 

- 

g - 

S 13 

S 14 

$ 15 

g 16 

£ 17 

$ IS 

$ 19 

$ 20 

$ 21 

$ 22 

£ 23 

S 24 

£ 10 

$ 

7 

$ - 

$ 239 

Disposal 

s 

$ 

$ 

$ 

- 

s - 

$ - 

$ - 

$ - 

$ - 

5 - 

$ - 

$ - 

$ - 

$ - 

$ - 

$ - 

s - 

£ - 

$ 

5 

$ 10 

$ 

15 


Table 33. Alternative 2 Cost per Life Cycle Year. 



2016 

2017 

201S 

2019 

2020 

2021 

2022 

2023 

2024 

2025 

2026 

2027 

202S 

2029 

2030 

2031 

2032 

2033 

2034 

2035 

Totals 

Procurement 

£ 9S0 

$ 

l r 7S0 

s 

750 

£ 100 

$ - 

£ - 

$ - 

$ - 

$ - 

£ 599 

£ - 

£ - 

£ - 

$ - 

£ 324 

£ - 

$ - 

£ - 

g - 

$ - 

$ 

5.033 

Integration 

$ 

£ 298 

$ 

64S 

£ 428 

£ 138 

$ - 

$ - 

$ - 

$ - 

$ - 

$ - 

$ - 

$ - 

£ - 

£ - 

$ - 

$ - 

$ - 

$ - 

$ - 

$ 

1.512 

Logistics 

$ 

$ 

$ 

- 

5 - 

$ 335 

$ 335 

£ 336 

£ 337 

£ 333 

£ 339 

£ 390 

£ 391 

$ 392 

$ 393 

£ 394 

$ 395 

£ 396 

$ 397 

$ 398 

$ 393 

£ 

6,264 

Operations 

£ 

$ 

£ 

- 

$ - 

$ 298 

£ 299 

£ 300 

5 301 

£ 302 

£ 303 

$ 304 

£ 305 

£ 306 

£ 307 

£ 308 

£ 309 

£ 310 

£ 140 

$ 100 

£ - 

£ 

4,192 

Maintenance 

£ 

$ 

$ 

- 

£ - 

£ - 

£ 55 

£ 55 

$ 56 

£ 56 

£ 57 

$ 57 

£ 5S 

£ 58 

$ 59 

£ 59 

£ 60 

£ 60 

S 35 

£ 15 

£ - 

£ 737 

Disposal 

£ 

$ 

$ 

- 

£ - 

$ - 

£ - 

$ - 

s - 

£ - 

£ - 

£ - 

£ - 

$ - 

$ - 

$ - 

£ - 

s - 

£ - 

£ 7 

£ 12 

$ 

19 
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Table 34. Spreadsheet used to Normalize FY11 Costs, 


Item 

Acquisition $ M or 
K/unit 

O&S $ M or K 

/unit 

O&S 6 sys/yr 

$M 

LCC 6 sys 

$M 

Inflation Scale 

LCS Ship 2 






FY10 

680.00 

43.00 

258.00 

3870.00 

Inflation Rate 

FY11 

689.52 

43.60 

261.61 

3924.18 

1.4 







UAV’s 1 






FY06 

7.00 

3.94 

47.30 

793.56 

Inflation Rate 

FY07 

7.19 

4.05 

48.58 

814.99 

2.7 

FY08 

7.36 

4.15 

49.75 

834.55 

2.4 

FY09 

7.47 

4.21 

50.49 

847.06 

1.5 

FY10 

7.55 

4.25 

50.99 

855.45 

0.99 

FY11 

7.65 

4.31 

51.71 

867.43 

1.4 







SH-60 3 






FY04 

42.42 

28.00 

336.00 

5040.00 

Inflation Rate 

FY05 

43.60 

28.78 

345.41 

5181.12 

2.8 

FY06 

44.96 

29.68 

356.12 

5341.73 

3.1 

FY07 

46.17 

30.48 

365.73 

5485.96 

2.7 

FY08 

47.28 

31.21 

374.51 

5617.62 

2.4 

FY09 

47.99 

31.68 

380.13 

5701.89 

1.5 

FY10 

48.46 

31.99 

383.89 

5758.34 

0.99 

FY11 

49.14 

32.44 

389.26 

5838.95 

1.4 








The 


above table was used to properly 


apply the 2010 inflation rates 


to 


system 


elements to normalize the FY11 pricing. 


156 






























Table 35. Spreadsheet 1 used to Estimate CTF-151 Costs. 


Ship 

cost per 
Ship ($B) 

total 

acquisiti on 
cost ($B) 

added 

item 

(RHIB, 
UAV, 
Helo) ($B) 

total added 
cost ($B) 

LCC from 

acquisition 

factor 

LCC 2010 

LCC 2011 
($M) 

Qtv 

TOC($M} 

DDG-51 

$1.5050 

$1.5050 

$0.0882 

$1,593 

1.94 

$3,042 

$3,085 

1 

$3,084.59 

FFG-7 

$0.6710 

$1.3420 

$0.0008 

$1,343 

1.13 

$1,500 

$1,521 

2 

$3,042.00 

LPD-17 # 

$1.2050 

$1.2050 

$0.0002 

$1,205 

1.37 


$1,649 

1 

$1649.44 

Jianwei 

$0.1540 

$0.3080 

'$0.0008 

$0,309 

1.13 


$349 

2 

$697.00 

Ulsan 

$0.1190 

$0.1190 

$0.0002 

$0,119 

1.13 


$135 

1 

$134.70 

Barbaros 

$1.0140 

$3.0420 

$0.0272 

$3,069 

1.94 


$1,967 

3 

$5,901.48 

La Fayette 

$0.3100 

$0.6200 

$0.0178 

$0,638 

1.13 


$711 

2 

$1421.31 

Iroquois 

$1.1590 

$1.1590 

$0.0119 

$1,171 

1.13 


$1,323 

1 

$1323.12 

Floreal 

$0.1860 

$0.1860 

$0.0122 

$0,198 

1.13 


$224 

1 

$223.97 

Totals 

$6.32 

$9.49 

$0.16 

$9.65 

$12.03 

$4,542.00 

$10,963.13 

14 

$17,477.61 


LCC Grand Total 

$17,477.61 
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Table 36. Spreadsheet 2 Used to Estimate CTF-151 Costs. 


ship 

Quantity RHIB Boats 

Cost RHIB ($M) Helicopter Cost Helicopter ($M) UAV System Cost UAV System ($M) Total Cost ($M) 

DDG-51 

1 

2 

$0,100 

2 

$42.40 

1 

$3.20 

$88.20 

FFG-7 

2 

4 

$0,100 





$0.80 

LPD-17 

1 

2 

$0,100 





$0.20 

jianwei 

2 

4 

$0,100 





$0.80 

lllsan 

1 

2 

$0,100 





$0.20 

Barbaras 

3 

6 

$0,100 

2 

$42.40 



$256.20 

La Fayette 

2 

4 

$0,100 

2 

$42.40 



$170.00 

Iroquois 

1 

2 

$0,100 

2 

$42.40 

1 

$3.20 

$88.20 

Floreal 

1 

2 

$0,100 



1 

$12* 

$12.20 
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APPENDIX G HEAVY UAV WEIGHT VALUE FUNCTIONS 


System specifications provide information needed to determine requirements and 
constraints for modules on each alternative for storage and handling purposes. This will 
help stakeholders determine which alternative module is most suitable for their needs. 
Specifications for each system include the weight (in pounds), and flight endurance (in 
hours). Research of system documentation was the most widely used method of 
determining the specifications. Confirmed system specifications, as well as best effort 
estimates, provided inputs to the OARS mission. 

Specifications for each element reviewed using a value model can be found in 
Appendix G, Heavy UAV Weight Value Functions. An example value model for the 
UAV is shown in Figure 61. The attributes of this element were broken down into the 
following: Weight, Speed, Range, Endurance, Payload, and Maximum Altitude (height). 



Figure 61. Alternative Match-Up of Life Cycle Costs. 
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Table 37 details the total measured value and the costs for each of the UAV 
elements under consideration. In order for decision makers to understand the raw data 
better, these data points were graphed in Figure 62 below. 


Table 37. Lightweight UAV Costs versus Measure of Value. 


Light-Weight UAV 



Cost$K 

Value Measure Total 

Silver Fox 

50 

0.225 

Mlanta B 

40.5 

0.577 

Scaneagle 

120 

0.696 

Exdrone 

110 

0.5935 


Efficiency Frontier 



Cost of Light-Weight UAV $K 


Figure 62. Alternative Match-Up of Life Cycle Costs. 
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The ScanEagle and Manta B UAVs were on the efficiency frontier in Figure 62. 
The data shows that the ScanEagle was the preferred choice between the two, due mostly 
to the preferred elevated endurance of the ScanEagle. The value preference model data 
and the corresponding characteristic attributes were exactly the same as the light UAVs 
as seen in Figure 61. 


Table 38. Lightweight UAV Costs versus Measure of Value. 


Attribute Contribution to Overall Value Measure 

Totals 

Alternatives 

Weight 

Speed 

Range 

Endurance 

Payload 

Height 


Silver Fox 

Q.Q50 

0.030 

0.000 

0.145 

0.000 

0-000 

0.225 

Manta 6 

0,007 

0.136 

0.188 

0.105 

0,016 

0,126 

0,577 

Scaneagle 

0.036 

0.000 

0.250 

0.250 

0.010 

0.150 

0.696 

Exdrone 

0.000 

0.200 

0.250 

0.000 

0.100 

0.044 

0,594 


The Heavy UAV comparison of cost and value totals is shown in Table 39 below. 
The data applied to a graphic presentation can be found below in Figure 63. The data 
shows that two UAV systems appear in the efficiency frontier. The UAV system that 
stands out as the dominate system is the MQ-4C, which is located on the upper left 
quadrant. The Euro Hawk is slightly more expensive due mainly to the addition of export 
requirements that would be necessary for a European military market. 


Table 39. Heavy UAV Costs versus Measure of Value. 


Heavy UAV 

Cost $M 

Value Measure 

Total 

MQ-4C-BAMS 

210 

0.3305 

Global Hawk 

220 

0.73 

Euro Hawk 

221 

0.869 

Mariner (Predator B, BAMS) 

N/A 

N/A 
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Figure 63. Heavy UAV Costs versus Preference Value Total. 


The final selection of elements to the OARS system was with regard to the RHIB 
pursuit vessels. Appendix F contains the Value Functions for each attribute, which are: 
Payload, Speed, Range, Length, Weight, and Beam. These attributes make up the 
respective column headings in Table 40. Table 41 below matches the value totals with 
costs per RHIB. 


Table 40. RHIB attribute Contribution to overall Value Measure. 


Attribute Contribution to Overall Value Measure 

Totals 

RHIB 

Length 

Beam 

Weight 

Speed 

Payload 

Range 


USMI 

0.010 

0.018 

0.013 

0.020 

0.005 

0.285 

0.351 

Willard Marine, Inc. 

0.010 

0.000 

0.000 

0.000 

0.200 

0.000 

0.210 

ASIS 

0.000 

0.100 

0.050 

0.073 

0.000 

0.195 

0.418 

Zodiac Midline 3 

0.100 

0.025 

0.028 

0.250 

0.024 

0.300 

0.727 
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Table 41. RHIB attribute Contribution to overall Value Measure. 


RHIB 

Cost $ K 

Value Measure 

Total 

USMI 

456.589 

0.35 

Willard Marine, Inc. 

107.177 

0.21 

ASIS 

94 

0.42 

Zodiac Midline 3 

71.417 

0.73 


Figure 64 below presents the RHIB data via a graph and helps to explain the 
choices remaining for the RHIB selection process. The dominated region in the lower 
portion of the graph shows the elements that would not be preferred. The remaining 
system, the Zodiac, is above the “dominated region” due to its preferred characteristics. 
According to Figure 64, the Zodiac appears to be the clear winner. 


Dominated Region 



Cost of RHIB UAV $K 


Figure 64. Heavy UAV Cost versus Preference Value Total. 
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Heavy Weight UAVs | _ Atribute Data 




Alternatives 

Max Gross Take 
off We ght 

Range 

Payload Capacity 
interior/exterior 

Max 

Altitude 

Max 

Endurance 

Max Air 

Speed 





lbs 

nm 

lbs 

ft 

hrs 

knt 




MQ-4C-BAMS 

3225C 

8200 

5600 

56500 

28 

331 




Global Hawk 

26700 

11000 

2900 

65000 

31 

545 




Euro Hawk 

25600 

12000 

2000 

65000 

35 

543 




Manner (Prede 

10500 

10000 

3850 

50000 

30 

240 






Attribute Data in Value Scale 






MCKC-BAMS 

0.00 

0 00 

1.00 

0.35 

0.00 

0.89 




Global Hawk 

0.32 

0.98 

0.24 

1.00 

0.44 

1.00 




Euro Hawk 

0.38 

1.00 

: oo 

1.00 

1.00 

1.00 


Attribute 

Weight 

Manner (Prede 

1.00 

0.90 

0.51 

0.00 

0.26 

0.00 


Weight 

0.05 









Speed 

0.20 


Attribute Contribution to Overall Value Measure 


Totals 

Range 

0.25 

MQ-4C-8AMS 

0.00 

0.00 

0.10 

0.05 

0.00 

0.18 

0.331 

Duration 

0.25 

G oba Hawk 

0.02 

0.25 

0.02 

0.15 

0.11 

: :c 

0.745 

Payload 

O.IO 

Euro Hawk 

C.02 

0.25 

O.OC 

0.15 

0.25 

0.20 

0.869 

Height 

0.15 

Mariner (Prede 

0.05 

0.23 

0.05 

0.00 

0.07 

0.00 

0.391 


1 

0.9 

0.6 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 


Weight Value Function 
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APPENDIX H RHIB WEIGHT VALUE FUNCTIONS 


RHIBS Atribute Oata 




Manufacturer 

Length 

Beam (m) Weight (lbs) 

Speed (kts) 

Payload(lbs 

Range (nm) 

Capacity 




USMI 

11.00 

3.20 

17,400 

46.00 

3200 

200nm 

13.00 




Willard Marine, Inc. 

11.00 

3.70 

22,000 

45.00 

18000 

HOnm 

26.00 




ASIS 

9.80 

3.10 

3190 

48.00 

3000 

127nm 

21.00 




Zodiac Midline 3 

11.12 

3.23 

11155 

57.00 

4850 

210nm 

10.00 







Attribute Data in Value Scale 






USMI 

0.820 

0.180 

0.250 

0.080 

0.025 

0.990 

0.200 




Willard Marine, Inc. 

0.820 

0.000 

0.000 

0.000 

1.000 

0.000 

1.000 


Attribute 

Weight 

ASIS 

0.000 

1.000 

1.000 

0.250 

0.000 

0.550 

0.700 


Weight 

0.150 

Zodiac Midline 3 

1.000 

0.250 

0.580 

1.000 

0.120 

1.000 

0.000 


Speed 

0.200 










Range 

0.250 



Attribute Contribution to Overall Value Measure 



Totals 

Beam 

0.050 

USMI 

0.041 

0.009 

0.038 

0.020 

0.005 

0.248 

0.020 

0.360 

Payload 

0.200 

Willard Marine, Inc. 

0.041 

0.000 

0.000 

0.000 

0.200 

0.000 

0.100 

0.241 

Length 

0.050 

ASIS 

0.000 

0.050 

0.150 

0.063 

0.000 

0.138 

0.070 

o 

i 

■ 

Capacity 

0.100 

Zodiac Midline 3 

0.050 

0.013 

0.087 

0.250 

0.024 

0.250 

0.000 

0.674 
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APPENDIX I LCC OF THE OARS ALTERNATIVES BROKEN 
DOWN BY FUNCTIONAL OBJECTIVES 

Each OARS alternative will procure systems according to the assessment made in 
the Recommended Alternatives section. Costs are displayed in four functional objective 
areas. Those areas are: 

• Detection in patrol. 

• Command, control & communicate. 

• Localize and track. 

• Engage. 

Due to some similarities between the two OARS alternatives, each of them will 
tally similar costs in the “Detection in Patrol” category. This is due to the fact that both 
alternatives utilize similar modern UAV sensor packages. Contrastingly, the two 
alternatives have some costs that vary distinctly due to the fact that the augmented OARS 
alternative utilizes a Broad Area Maritime Surveillance (BAMS) system, whereas the 
Basic OARS system does not. 

A. ALTERNATIVE #1, OARS BASIC 

The cost of the primary search sensor, the UAV system, is roughly 13 times 
cheaper than all other detection system costs combined for Alternative 1. Procurement 
costs of the UAV systems are quite small compared to the overall procurement cost. The 
costs associated with procuring surface sensors are identical between both alternatives. 
All LCS platforms have the same radar, EADS-Air search, and Sea Giraffe-surface 
search capabilities, thus they all have the same costs. 

Figure 65 shows the LCC of Alternative 1 broken out by functional objectives. 
The bulk of the costs center around the LCS host ship system and since Alternative 1 
utilizes six host ships, this cost is very large. 
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Alternative 1 LCC by Functional 
Objective 

■ Detection 

■ C-3 

Localization and 
Tracking 

■ Engagement 


Figure 65. Alternative 1 LCC by Functional Objective. 

B. ALTERNATIVE #2, OARS AUGMENTED 

Procurement costs for Alternative 2 also consist of each of the four functional 
objectives. Figure 66 shows that this alternative allows the funding for surface sensors to 
grow in parity to the remaining three functional objectives. Due to the Alternative 2’s 
addition of an air-borne surface sensor, the total procurement costs are increased, thus 
making this the more expensive alternative. 

Airborne surface sensors remained the largest functional objective with 27% of 
the total costs. Airborne surface sensor costs are split between the SH-60 Helicopter and 
the UAVs, but the primary sensor is the UAV. Distribution of the remaining costs will 
weigh heavily on combat systems at 29%. 



174 



Alternative 2 ICC by Functional 
Objective 



■ Detection 

■ C-3 

■ Localization and 
Tracking 

■ Engagement 


Figure 66. Alternative 2 LCC by Functional Objective. 


The total funding amount is largely affected by the procurement cost of the host 
ship platforms. However, the addition of Alternative 2’s BAMS system increases the 
procurement cost within the surface detection functional objective from 15% in 
Alternative 1 to 27% in Alternative 2. The Zodiac Rigid Hull Inflatable Boats (RHIB), 
which are utilized as pursuit vessels in both alternatives, represent the lowest 
procurement cost items in each of the alternatives at $0,852 Million. The .50 caliber 
machine guns represent roughly $2,032 Million of material that will be affixed and 
deployed on the RHIB boats. The RHIB gun element was priced with one million rounds 
in procurement. In contrast to the surface engagement RHIB boats, the primary airborne 
engagement element of the OARS system, the SH-60 Sea Hawk Helicopter, will assume 
roughly 16% of the procurement costs. 

The introduction of the BAMS system accounts for 18% of the LCC at almost 
$3.2 billion. The preference model in Appendix G dictated the use of the Global Hawk 
or Euro Hawk BAMS vehicle from a superior flight endurance point of view. 
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LCC versus FO Comparison 



Functional Objectives 


■ OARS AUGMENTED 

■ OARS BASIC 


Figure 67. LCC versus Functional Objective Comparison. 

Figure 67 and Table 42 illustrate a comparison of both OARS alternatives’ Life 
Cycle Costs broken out by their functional objectives. As mentioned above, the OARS 
Augmented option was the most expensive option. 


Table 42. LCC by Functional Objective Comparison. 


Life-Cycle Cost by 
Function 

Detection 

C-3 

Localization and 
Tracking 

Engagement 

Total 

OARS BASIC 

$ 2320 Million 

$4484.6 

Million 

$4175.3 Million 

$4484.6 Million 

$15465 Million 

OARS 

AUGMENTED 

$ 4783 Million 

$4439 Million 

$4110 Million 

$4438.5 Million 

$ 17770.5 
Million 
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